Long-term architecture for supporting different providers

[Arithmomaniac]

As mentioned in #70 , it may be time to start thinking about how we want to support multiple providers in the long run. I was thinking something as follows:

1. There would be a base Gravity.Base project/package that would contain BaseDto, relevant helper methods, and an IGravity(Async)Repository interface containing a basic CRUD contract for all implementations. This would correspond to, e.g. RsapiDao now.
2. Each implementation would get its own Nuget project/package, to prevent needing tons of dependencies (e.g. Gravity.RSAPI).
   • Each package would have the IGravity(Async)Repository implementation, which in turn would in turn take a thin provider to abstract away calls to and from the server (e.g. RsapiDao would be renamed RsapiRepository would have an RsapiProvider similar to the one in #3 create RsapiProvider #70).
   • The repository itself would handle issues like field mapping, recursive calls, etc.
3. To implement IGravityRepository.Query, each provider would need to include a LINQ Provider, as per LINQ Provider #12. We could have missing implementations throw NotSupportedException, create a separate IQueryableGravityRepository implementation, or just leave Query out of the base interface.

If this sounds right, we can decide how we'd like to create a project around it.

[Arithmomaniac]

Related to #154