Simplify documentation of "constraints" overview (#6257)

The current documentation overview for
[Constraints](https://yarnpkg.com/features/constraints) reads somewhat
like a sales pitch, rather than documentation. It's a bit wordy, and
kind of grammatically incorrect/confusing. It might be more beneficial
to mention "enforcement of workspace package rules" as the main point,
rather than towards the end of the description. Additionally,
constraints can be used for a large number of needs that are not
necessarily "basic" ones.

I'd be fine with expanding the example list, but being sure to specify
that these are just examples of how constraints are commonly used.
They're not the limit of the capability.

## What's the problem this PR addresses?

Unclear documentation.

## How did you fix it?

Made it a bit more clear and simple.

## Checklist

<!--- Don't worry if you miss something, chores are automatically
tested. -->
<!--- This checklist exists to help you remember doing the chores when
you submit a PR. -->
<!--- Put an `x` in all the boxes that apply. -->
- [ ] I have read the [Contributing
Guide](https://yarnpkg.com/advanced/contributing).

<!-- See
https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released
for more details. -->
<!-- Check with `yarn version check` and fix with `yarn version check
-i` -->
- [ ] I have set the packages that need to be released for my changes to
be effective.

<!-- The "Testing chores" workflow validates that your PR follows our
guidelines. -->
<!-- If it doesn't pass, click on it to see details as to what your PR
might be missing. -->
- [ ] I will check that all automated PR checks pass before the PR gets
reviewed.

Author: jeremy-daley-kr

packages/docusaurus/docs/features/constraints.mdx

@@ -11,7 +11,10 @@ This page documents the new JavaScript-based constraints. The older constraints,
 
 ## Overview
 
-Constraints are a solution to a very basic need: you have a lot of [workspaces](/features/workspaces), and you need to make sure they use the same version of their dependencies. Or that they don't depend on a specific package. Or that they use a specific type of dependency. Whatever is the exact logic, your goal is the same: you want to automatically enforce some kind of rule across all your workspaces. That's exactly what constraints are for.
+Constraints allow enforcement of rules across [workspace](/features/workspaces) packages. For example, these rules might include the following:
+
+* Ensuring the same version of dependencies across packages.
+* Prohibiting the use of specific dependencies in packages.
 
 ## What can we enforce?