Support for other DI frameworks

In the discussion at https://github.com/corvus-dotnet/Corvus.Identity/pull/202#discussion_r756278658 @jongeorge1 raised this point in the light of various classes being `internal` and accessible only through DI:

>I understand the reasoning behind making these classes internal, but I'm not a huge fan. I've run into problems trying to use Corvus libraries in a scenario where the MS DI framework isn't in play, but we can't register the required classes in other DI frameworks because they are internal.
>
>I think there's a case to be made for making them public, given that we have them in an Internal namespace which gives a good indication that it's not normal to be consuming these classes directly. Thoughts?

In theory, the use of `Microsoft.Extensions.DependencyInjection.Abstractions` doesn't require the use of Microsoft's DI framework. One of the reasons they put all the types supporting registration in there is to make it possible to register dependencies in a framework-independent way. In theory at least, all it takes is an alternative implementation of `IServiceCollection` as an adapter to whatever framework you want to use.

This is exactly what Azure Functions do: they use a different DI container. ("DryIoc" if I remember rightly.) So it's definitely possible.

So the questions are:

* are there DI frameworks for which this is impossible?
* are there DI frameworks that look sufficiently different that this adapter approach works badly?
* are there DI frameworks for which this would be feasible but no adapter exists?

If there are frameworks we care about for which either of the first is true, then making the relevant types public seems like a good idea. But if not, currently my preference would be not to do it because it increases the surface area of the library for backwards compatibility purposes.

Start with the linked pull request discussion and review how the library exposes classes through Microsoft.Extensions.DependencyInjection.Abstractions. Investigate whether the DI frameworks mentioned in the issue can use adapters, and identify which framework scenarios would require public types. Done should be a documented decision on supported frameworks and the resulting API changes.

Written by the indexing model from the issue text.