[MS.DI] Use DryIoc sources directly for the DryIoc.Microsoft.DependencyInjection package

[dadhi]

There are a number of problems with abstracting away from the DryIoc and keeping it as dependency:

1. We have two IServiceProvider abstractions, the first is the DryIoc.Container itself and the second is the DryIocServiceProvider wrapper inside the MS.DI. The reason for the latter is that the same IServiceProvider object should implement the ISupportRequiredService from the Microsoft.Extensions.DependencyInjection.Abstractions. So either I depend on the MS.DI abstraction package in DryIoc (I don't want to) or I am doubling on the IServiceProvider implementation, complicating things.
2. The second reason is the performance/memory, and is partially related to the first point. Having additional abstraction build for the MS.DI adapter just for the sake of wrapping things includes the performance cast or indirection and growing memory. Why do I need a separate object for IServiceProvider or for IServiceScopeFactory if this functionality is already implemented in Container. There is open question about the separate scope wrapped implementing a IServiceScope.

Pros:

• No additional dependency on DryIoc. Consequently, it may simplify usage of the comp-time features delivered with the source content package.
• Possibility to fine tune the DryIoc internals (think better performance) for the MS.DI without back thought on the general audience. The DryIoc namespace may be changed to the Microsoft.Extensions.DependencyInjection.DryIoc to avoid conflict with the separate DryIoc package.

Cons:

• Fix in DryIoc requires additional package release.
• Complexity of handling #if logic in DryIoc sources.

[dadhi]

//cc @davidfowl If you see that, what are your thoughts?