Separate EntityFramework APIs into separate package

[jaredcnance]

We would like to support other ORMs such as Marten (see #291) and MongoDb (https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb). In order to do this, EF should not be installed unless the developer explicitly chooses it as their ORM. I'd like to see developers install their ORM specific version from the beginning (e.g. dotnet add package JsonApiDotNetCore.EntityFramework) which will bring the base library (JsonApiDotNetCore) in as a transient dependency.

So, the dependency chain will look something like:

JsonApiDotNetCore.EntityFramework -> JsonApiDotNetCore -> Microsoft.AspNetCore., ...
JsonApiDotNetCore.Marten -> JsonApiDotNetCore -> Microsoft.AspNetCore., ...
JsonApiDotNetCore.MongoDb -> JsonApiDotNetCore -> Microsoft.AspNetCore.*, ...

The roadmap for doing this will look something like:

• v2.x : removal of EF APIs into separate project installed by default, dependency chain looks like JsonApiDotNetCore -> JsonApiDotNetCore.EntityFramework. This allows us to begin separation in a non-breaking way.
• v3 : complete separation and inversion of dependency. This will require application developers to install the new package and possibly change namespaces...(namespace changes could be amortized through deprecations and proxies)...

Blocked by #254

[bart-degreed]

The current situation is that we have EF Core support built-in and MongoDB support in an external package. But ironically, MongoDB today depends on EF Core-specific code in JADNC to produce its expression trees.

We could make the split today, but the hard question is: what belongs where? Once we have a few implementations for different data storage technologies, we can better answer that question, so I think we should postpone this work for now.

Splitting also means we'll need to untangle bootstrap code that scans EF Core models to build the resource graph and register various IoC container implementations. Without those registrations, JADNC cannot function, because no implementations are registered. In general, it's easier for JADNC consumers to replace a few registrations to customize, rather than first requiring to implement lots of interfaces before a simple request can succeed when not using EF Core.