Reverse the DI container configuration responsibiltiy

[mauroservienti]

We have a strong dependency on a DI container, like it or not that's a fact.

Given the way things are actually designed implementing support for a container is a nightmare that comes to life. It is up to the user to understand what to register, how, when, and how to deal with BootstrapConventions. It is everything but a trivial task.

Now that we are going in the direction of a high level, DI container independent, ApplicationBootstrapper (See https://github.com/RadicalFx/Radical.Windows.Presentation/issues/21 and https://github.com/RadicalFx/radical-universal/issues/28) that utilizes a IContainerBootstrapper implementation as a mediator when talking to the DI container, I'm wondering if there is any value in moving the responsibility of deciding what to register, and how and when, to the ApplicationBootstrapper making the IContainerBootstrapper responsible for the physical registration only.

The clear advantage is that we move in the direction of making the task of implementing support for a new container a trivial task.

@micdenny thoughts?

[mauroservienti]

related to #6

[micdenny]

you can check how we did in EasyNetQ:

The container interface: IServiceProvider

The default container implementation: DefaultServiceProvider

And until now is our PuzzleContainer

The static helper to bootstrap the library: RabbitHutch

as you can see we simple expose a SetContainerFactory method so you can really easily replace the container before calling the factory method:

RabbitHutch.SetContainerFactory(new WindsorAdapter(new WindsorContainer()));

and creating a container is really a trivial task: WindsorAdapter

[mauroservienti]

Withdrawing this as we moved to IServiceCollection as a mediator between Radical and IoC containers.