Always using outside of namespace.

We don't need to expose this in the client.

Because the sync ones end up calling the async ones. This way all the dataset methods on KeenClient are covered.

Also refactored the tests to be a bit neater

…setsBranch

# Conflicts:
#	Keen/KeenConstants.cs

…CaseNamingStrategy`, so use that.

- The back end actually supports receiving either string or list of strings for both `index_by` and `group_by`.
- In both cases it returns a list anyway.

- A few comments/whitespace/formatting issues.
- Share code between PutAsync()/PostAsync().
- Move QueryDefinition extensions that are specifically for datasets to the `Keen.Core.Dataset` namespace.

…d also fix capitalization.

- Still need to add or elaborate on comments for lots of public members.

- At this point all the tests pass, at least.

…path in Windows, Linux and MacOS without issue.

- Regarding *Async() methods in KeenClient.cs, for simple forwarding methods, just return the task directly. No need to await or configure the awaiter...either way, internally our impls configure awaiters properly everywhere, and a 3rd party impl of, say IQueries could fail to do so and cause blocking on our task to potentially deadlock anyway, depending on the sync ctx. Anywhere there are calls to multiple async APIs we go ahead and await/configure as expected.
- One actual ramification of returning tasks is that in a few places where we validate params, we'll throw synchronously now instead of when the task is awaited, so potentially if you call us and store the task to await later, the client code's try/catch could be in the wrong place, but that seems like it's not that huge a deal as long as we bump the minor version (still pre-v1.0).
- Some of the Datasets code was incorrectly demanding a MasterKey when it really only needs a ReadKey.
- Changing to ReadKey showed me that some of the tests that expect throwing situations wouldn't catch the wrong key, because we throw the same exception for the server returning 500 as for an incorrect key (KeenException). This could mean we should throw different exceptions, which would make testing this easier (and potentially make coding against the SDK easier). It could also be fixed in tests by checking for certain words in the error message, but I figured it was more straightforward and clear to separate that particular throwing condition into its own test for each of the create/result/definition(s)/delete functions.
- Changed GetQueries()->GetQueriesAsync(), since it's public and should indicate that it returns an awaitable.

…s for Datasets.