Decouple IMaven from IMavenExecutionContext

[laeubi]

Currently there is a strong connection between IMaven and IMavenExecutionContext and they even share packa-private methods to interact with each other. In #546 we implemented the idea to have an IMaven per project but with more and more implementation of this I think this do not fit well and we actually need an IMavenExecutionContext per project instead. I also noticed when now inspecting the "multiple plexus container" story that this do not maps well to the current IMaven entry point.

The reason I think this is much better suited is, that IMaven holds a lot of stuff that is independent of the project (e.g. configuration loading/storing of models) and just for the matter of execute some stuff it delegates actually to the IMavenExecutionContext and that would also much better match the maven execution workflow where one can be sure that one project is executed (but probably others in parallel) at one time.

Thus I'd like to propose the following:

1. Move everything related to "execute" into the IMavenExecutionContext, this could be archived for example by making the context() function available, as this is some kind of "thread realm" you can connect to, this is just hidden currently and gives a false expression that a context is not needed when calling those methods.
2. remove IMavenProjectFacade.getMaven() and instead have IMavenProjectFacade.getExecutionContext()
3. add a static context() method to the IMavenExecutionContext that behaves as a replacement for the current entry-points in IMaven for executing code with maven

Please let me know what you think, I can try to provide some PRs with smaller increments if we can agree on this and think, even though this is a larger conceptual change, that this would make m2eclipse architecture much more clean and powerful and easier to match to the maven world.

[mickaelistria]

While working on it, I came to similar ideas that this IMaven interface is doing too much and is making it harder to implement the flexibility. But I'm also unsure we want to just stick to IMavenExecutionContext as project specific stuff. Indeed, some methods like resolve, getSettings or even lookup can easily become project-specific if some different settings are set eg in .mvn/maven.conf. So I think we will easily still need more that execution context from a MavenProjectFacade.

[laeubi]

Yes, I think IMavenExecutionContext must still interact with IMaven, but I think this will not be that "static" as it currently is, e.g. resolve would mostly make sense in an active execution as well, settings are (if we want allow project specific ones) also most probably has to be checked (like .mvn/maven.conf)at the momment where we actually execute e.g. it can change at any time. and for lookup again I think there will always be some "static" containers to check and then some where we want to dynamically find things (e.g. wile executing mojo executions) so my idea would be seperate those then, e.g. we can have a lockup method inside IMavenExecutionContext that looks up a component for the current running execution (that then might include extensions as well).

But for now I think we could start with the execute methods and pass on these topics later on as these obviously (for me) don't belong to the IMaven and make the whole thing hard to understand / adjust / refactor currently. So my first try would be to move org.eclipse.m2e.core.internal.embedder.MavenImpl.createExecutionRequest() (what is protected) and the basedir to the IMavenExecutionContext and see if the recently added test still work.

Does this sounds reasonable?