[Discovery] Improve common constraints experience about edx-lint

[robrap]

Original comment from @timmc-edx:

Robert and I discussed an alternative to the wget/sed approach today:

1. Specify constraints like django==4.0.8 # common-constraints=override in constraints.txt – this comment will indicate that this package should not be constrained by common-constraints.
2. make compile-requirements fetches a Python script from edx-lint and executes it.
3. The script pulls down a copy of common-constraints.txt and reduces it to only the constraints that don’t have the override annotation.
4. constraints.txt continues to include -c common-constraints.txt but can also have a comment describing how to put an override in place.

Effects:

• A developer looking at or modifying the constraints file would know the current status of any overrides (good locality)
• Only one repo (edx-lint) would need to be modified when we want to change our process, as the script would be downloaded each time

[robrap]

The following is related to common-constraints.txt, but may be an entirely separate question:

In #349 (review), a common constraint was removed once the openedx org was ready, but the edx org repos were not necessarily ready. The question is whether or not we need a capability for adding org specific common-constraints?