[MNG-8569] Deprecate and remove version ranges

**[Elliotte Rusty Harold](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=elharo)** opened **[MNG-8569](https://issues.apache.org/jira/browse/MNG-8569?redirect=false)** and commented

To protect Maven users, we should eliminate, or at the very least warn, when version ranges are used in dependency elements. See https://jlbp.dev/JLBP-14 for the rationale. tldr; version ranges make projects vulnerable to malicious changes of ownership in dependencies that can lead to remotely exploitable arbitrary code execution. I'd rate this about a 9.0 on the severity scale.

I don't know of an attack using this vector in Java (yet) but it has
been used multiple times in other ecosystems to steal bitcoins and
install malware. Java has been lucky so far, but we are by no means
immune to it.

Since this is a compatibility breaking change, which I don't take likely but IMHO is worth it in this case, use a multi-step process:
1. Discourage this in the docs for version ranges, especially the POM reference.
2. Warn about this in the build when version ranges are encountered.
3. Formally deprecate the relevant code in the repo. (Might not be necessary.)
4. Add a switch (system property) to disable version ranges. Switch is off by default.
5. Turn the switch on by default. 
6. Remove the switch.

This might take a few years, so let's start now. It's also possible an active attack will push us to do this overnight. If we start now, maybe we'll be lucky enough to avoid emergency responses in the future.

---

**Issue Links:**
- [MNG-8652](https://issues.apache.org/jira/browse/MNG-8652) Support prefix version ranges for better interoperatibility

- [MNG-6049](https://issues.apache.org/jira/browse/MNG-6049) Add behavior to filter resolved version ranges of an artifact

Start by reading the version-ranges documentation, especially the POM reference, and then locate the dependency build path where version ranges are encountered. Map the proposed warning, deprecation, system-property switch, default change, and eventual removal into separate stages. Done means the project has an agreed compatibility plan and corresponding documentation, build behavior, and tests for each stage.

Written by the indexing model from the issue text.