Rationalize and centralize query generation code

[jansenbe]

Today we build get/update/delete queries in a more or less centralized manner (Add queries are created within the respective model classes). Should we further centralize all but the Add related query code. Quick inventory shows we're creating queries in here:

BaseDataModel
internal async Task BuildGetAPICallAsync(EntityInfo entity, ApiCall apiOverride, bool forceSPORest = false, bool useLinqGet = false)
internal async Task BuildUpdateAPICallAsync(EntityInfo entity)
internal async Task BuildDeleteAPICallAsync(EntityInfo entity)

BaseDataModelCollection
Paging related Url handling code

ODataQuery & DataModelQueryService
Translates LINQ information into a query

What if we would have a centralized QueryService that can be injected via DI and that will centralize all the query creation logic? This will make it easier to ensure both linq as regular approaches stay in sync with regard to the more advanced query options. This will also improve testability as we could write test cases that just focus on query building/validation.

Relates to #132 and #140

Adding @PaoloPia , @ypcode , @pkbullock and @JarbasHorst for awareness.

[ypcode]

Again great improvement for general quality and clearness of the code :) Great job @jansenbe

(I am sorry for the leave of feedback, I usually get the notifications on the GitHub mobile app, but discussions are not included in it -_-)

[jansenbe]

I've centralized the BaseDataModel and BaseDataModelCollection code and wrote tests, so biggest part of this refactoring is done.

[jansenbe]

And now also added the logic in DataModelQueryService, the logic in ODataQuery is too LINQ specific and should stay where it is