[MSHARED-987] Drop legacy, prepare for future

[cstamas]

In general, support Maven 3.1+ only (drop Maven 3.0 support).

https://issues.apache.org/jira/browse/MSHARED-987

[slachiewicz]

not wort to reopen.. see here #20

[cstamas]

I think this deserves a new Maven Apéritif... Where I could explain why I think we need to keep m-a-t, but not in today's form (but with minimal, ideally no API changes affecting consumers of it) @michael-o @rfscholte @slachiewicz

[cstamas]

So, in the meanwhile (as we "facilitate" the Apéritif), the plan in short:

• return maven 3.0 support
• explode m-a-t into modules: m-a-t contains "api" and have a providers for maven3.0, maven3.1, maven4.0...(4 not really needed yet), m-a-t pulls in providers it knows about, so consumer still "just" depends on m-a-t, but they get all providers pulled in (no overlaps or having org.sonatype and org.eclipse on CP)
• for this to work, providers will use provided scope of maven internals and aether/resolver (basically each provider will use deps it's maven provides as provided)
• m-a-t defines all the API (as now), and providers provide SISU components implementing API using 3,0, 3.1 and so on
• this makes all the reflection not needed, and other hoops and loops as well, simplifies development as in each provider you code "cleanly" against given maven version and it's surroundings
• make Delegator "smarter" how to select what to lookup (similar as now, in this PR, but smarter)

[cstamas]

This is the pattern I want to implement: https://github.com/cstamas/providers

basically new "api" module, as many provider we want (maven3.0, maven3.1, ...) and "runtime" module from demo above will be "org.apache.maven.shared:maven-artifact-transfer", so consumer of that single artifact will work without a change.

[rfscholte]

https://github.com/apache/maven-artifact-transfer/tree/master/src/main/java/org/apache/maven/shared/transfer/project this package should be moved to Maven Core (maybe as part of Maven Artifact Resolver Provider).
It was put here because the install/deploy logic is used bu multiple plugins (incl. maven-invoker-plugin) and this library looked like the best option.
However maven-artifact-transfer shouldn't have had a dependency on Maven dependencies, it overcomplicate things and it is not part of the bridge function of this library.

[cstamas]

Superseded by #24