[Discovery] Improve common constraints experience

Issue description and initial comments moved from private ticket: https://2u-internal.atlassian.net/browse/BOM-2721

The process around common_constraints.txt has some issues as we work through upgrades.

1. It is not simple to override a common constraint in constraints.txt, which is where you might expect to do this when working through an upgrade that isn't yet available globally.
2. It is not clear how to mark and clean-up overrides once the common constraints can finally be removed.

See https://github.com/edx/auth-backends/pull/125#discussion_r685288124 for some related discussion.

Additional Notes:

• Some related docs updates:
  • Reminder: If we are making changes to a library based on a new or updated api in a dependency, we need to add and comment a new minimum requirement in base.in.
  • If we know that a library will break with an updated dependency, we should add a maximum constraint in to the library’s base.in, and not just rely on common_constraints.txt.
  • If we release an updated library that fixes and uses a newer version of a dependency that is in common_constraints.txt, we either need to:
    • remove the dependency from common_constraints.txt (if we are ready), or
    • add a maximum constraint to common_constraints.txt for the library update, so no one will try to pick up the new version of the library which will conflict with the active common constraint on the dependency.
      • See example: https://github.com/edx/edx-lint/pull/182

Start by reading common_constraints.txt and constraints.txt, then compare the dependency guidance in base.in with the discussion linked from edx-lint#125 and the edx-lint#182 example. The work is complete when the process for overriding common constraints, marking those overrides, and cleaning them up is clearly defined.