Find a replacement for the Key-Content-Type REST request header

A REST URI should uniquely identify a resource.
But in our server, the Key-Content-Type request header changes the way the URI is mapped to a cache key,
so a single URI could be seen by the server as multiple different cache entries.

The simplest solution would be to extend the URI of cache entries with a query parameter, e.g. /rest/v2/caches/<cache>/<key>?key-content-type=<media-type>.

I have 2 small concerns with this solution:
1. When doing a POST request, browsers will put all the parameters in the request body instead of the location.
I don't expect us to have browsers acting as clients, and the search request already does this, but something to keep in mind.
2. Although resource URIs can be anything, they are usually thought to include only the path part of the URL.
Everybody knows query parameters affect `GET` requests, but the difference between
`DELETE /rest/v2/caches/<cache>/<key>` and
`DELETE /rest/v2/caches/<cache>/<key>?key-content-type=application/octet-stream`
might be surprising to some.

I would prefer to put the key media type in the path of the URI,
e.g. /rest/v2/caches/<cache>/<key-content-type>/<key>.

It also has a problem: it makes it look like encodings create separate namespaces,
but they actually overlap, and the same logical "cache entry resource" can be accessed
with multiple key content types.

So perhaps we should instead say the /rest/v2/caches/<cache>/<key> resources are always text/plain;charset=UTF-8 keys,
and for any other content type the client should use a different resource, /rest/v2/caches/<cache>/entry/
(the extra / may or may not be required to avoid clashing with regular keys).
The /rest/v2/caches/<cache>/entry/ resource would have key and key-content-type parameters
that could be sent either in a `GET` query string or in a `POST` body.

Note: Some key content types will have additional parameters to tell the server how to decode them, e.g. application/x-java-object;type=java.long.Double, or application/octet-stream;encoding=hex.
I have created ISPN-11966 to deprecate the application/x-java-object handling, and ISPN-11968 to deprecate the encoding parameter in application/octet-stream.