[MRESOLVER-512] ScopeManager

[cstamas]

In Resolver 1.x times, resolver was unaware of "resolution scope", to get the wanted resolution scope caller had to tweak and set up various nits and bits, like selectors, filters, and so on. It was easy to miss. Similarly, resolver had no "first class" type for "dependency scope" either, they were just string labels (that everyone knew HOW should behave, but was never codified) and its meaning and notion was sprinkled across several classes. Introducing new scope in these conditions (or alter selector to something that would have new scopes, like Maven4 plans) was nearly impossible.

The ScopeManager aims to solve these issues: it defines "resolution scope" and "dependency scope", interprets them, and allows caller to simply make a call to "resolve me main-runtime" resolution scope. No hoops and loops. Moreover, it is FASTER than Resolver 1.x was, that used always same selector (to build dirty graph), so potentially huge graph even if you needed just a bit of it, that was later chopped down to clean up the graph. ScopeManager automates selector selection/setup, and goes directly for result, in most cases the resulting tree is done in first pass.

Finally, and most importantly, ScopeManager allows to be "configured": by supplying the recipe for dependency and resolution scopes, hence, makes Resolver 2.x versatile, in a sense, it is not "this or that" anymore, it can obey Maven3 and Maven4 dependency scopes at the same time.

---

https://issues.apache.org/jira/browse/MRESOLVER-512

[gnodet]

I'm really reluctant about this PR. This goes in the exact opposite direction than https://issues.apache.org/jira/browse/MRESOLVER-471, which aimed to make the resolver agnostic about scopes and leave these bits to be defined by Maven.

It basically replaces 250 lines of deprecated code (the JavaDependencyContextRefiner, JavaScopeDeriver and JavaScopeSelector which were deprecated a few weeks ago) with 3800 new lines of code, adds a strong tie between the resolver and maven, whereas the code could be easily moved into maven which already exposes those concepts.

[cstamas]

Well, IMO this PR goes exactly in direction of MRESOLVER-471, as:

• ScopeManager is optional, in a sense, if you want to use Resolver 2.x as you did Resolver 1.x, go for it
• ScopeManager solves the problem of "Resolver should be oblivious about scopes" (MRESOLVER-471), as Resolver 1.x implemented scope related logic scattered across several (dozen?) classes that cemented their semantics, moreover modifications like "introducing new scope" was nearly impossible exactly due that (as Resolver was not oblivious, but had them cemented as String constants spread across dozen classes). Hence Resolver was strictly "this xor that" (exclusive or).

With ScopeManager Resolver IS really oblivious about scopes, in a sense, they are not only "string labels with some coded meaning scattered across codebase", but they are defined by client project, the app that is integrating Resolver 2.

[gnodet]

@cstamas The whole SystemScopeHandler needs has to be removed/merged into ScopeManager imho. The isSystemScope really looks redundant with ScopeManager.getSystemScope().

[cstamas]

@gnodet applied changes, IMHO it looks even better now 😄