Support non-batch mechanism for long URLs

From the early days of OData we have had issues with requests exceeding the maximum URL length for servers.

The typical response has been to use $batch, which passes the request in the body. However, using $batch is a bit overkill for this common scenario, and has several drawbacks:
1) using $batch is non-intuitive and introduces extra complexity and concepts for executing a single request
2) the /$batch request and response must both be wrapped, with things like headers, request verbs, and response codes hidden within the payload.
3) the /$batch endpoint is at the root, which means that the request is not routed according the URL but the request body must be parsed in order to determine routing

Instead of relying on batch, we can define a /$query segment that can be applied to a resource path. Clients POST to the URL, providing the query string in the body. Any query options specified in the URL are combined with the query options specified in the body.

The format of the querystring in the body is an interesting discussion. One option is to provide it as a simple string, which would be the most consistent with the existing query string. Alternatively, we could provide a JSON payload of name/value pairs for each query string option. The two are not mutually exclusive; the client could indicate through the content-type header which format they are using (applicaiton/text versus application/xml).

We could also explore other structured representations of certain query options. For example, we could provide an AST representation of the $filter query option that could be simpler and more efficient to build and parse than serializing as a string.

The drawback to defining multiple formats is that services either need to support both, or clients need to check which format(s) are supported by the service.