Historically (from Maven3) "problem collection" (in various scenarios, like building effective settings and toolchains, to building models) were done by passing around `List<Problem>` structure. This proved quite ineffective, as in case of (really) huge projects with quite big count of problems reported choked Maven (but also produced unusable output). We are aware of projects producing 3 million warnings! Dumping all of them onto console/log makes really no sense.
This PR changes Maven that by default it reports "problems" (settings building, toolchains building, or model building) as one liner warnings: how much and where were problems collected. This produces much more less overwhelming output than happens on master. User can control "build errors" using `-e`, so `mvn -e` will dump errors on screen/log.
The new `org.apache.maven.api.services.ProblemCollector<P>` class, that is somewhat "drop in" replacement for `List`, but with huge difference: it is "lossy", in a way, it maintains counters precisely, but actual problem instances are simply dropped after threshold `maven.builder.maxProblems` is surpassed (default 100). See `org.apache.maven.api.Constants#MAVEN_BUILDER_MAX_PROBLEMS`.
Rules:
* on problem addition counters are always updated
* if below threshold, store the problem (and will be reported later to the user)
* if above threshold, try to drop one problem with severity lower than currently reported problem, if succeeded, store the current problem, otherwise drop it
---
https://issues.apache.org/jira/browse/MNG-8447
The decryption should happen transparently, also, resolver should not decrypt for itself only, whole maven should have access to all.
This PR also disables Maven 3.0 IT MNG-4459 as Maven4 stops with this "security through obscurity" (keep encrypted pw in memory kinda for "security reasons" but in reality any mojo or extension can decrypt anything they want).
---
https://issues.apache.org/jira/browse/MNG-8379
Detach maven-cli from maven-embedder (deprecated). Basically, classes are copied from embedder to cli, while embedder points to old classes and cli to new classes. **One important exception is logging**: the classes are _moved_ to cli, and embedder modified to use those classes (and dependency reversed: embedder now depends on cli). Reason is Verifier, that still calls into "hack method" of deprecated MavenCli, and then without logging classes move would explode due casting.
---
https://issues.apache.org/jira/browse/MNG-8332
Tamas Cservenak
Jermaine Hua
Guillaume Nodet
P. Ottlinger