Define optional HTTP 426 response for requests for index files

[jmarshall]

As proposed in #581 (comment), this PR defines an optional HTTP 426 response that servers can use to tell clients that they should be using htsget:

Clients attempting to access a resource directly, rather than via the htsget protocol, will likely also request index files alongside the requested resource. Add a section discussing how servers MAY respond with an HTTP 426 Upgrade Required status code, which provides a way to instruct the client to switch to the htsget protocol.

This functionality is orthogonal to an identifying marker on URLs such as a bespoke URL scheme or distinctive query parameter, as is being discussed on #581. Whether or not htsget recommends such a marker, it would IMHO be beneficial to define a mechanism that htsget servers can use to reject requests for index files by telling the client to use the htsget protocol instead.

The functionality could also provide an effective alternative to using an identifying marker: a client would make a request for an index file, receive a 426 response, and then know that the URL represents an htsget resource and in future know to make requests of this resource using htsget. This at the cost of one HTTP request/response round trip the first time the client accesses a particular resource (or server, if it uses suitable heuristics) — sensible clients would cache the knowledge that it is an htsget resource and make further requests for different genomic regions using htsget only.

Clients might open a request to the resource itself before they request any associated index files. The previous comment #581 (comment) discusses making non-htsget-parametered requests for the actual resource also return 426:

Whether to return 426 or an htsget ticket for a plain request for a valid resource is likely to be server-dependent. A case could be made for returning a ticket representing the entire file (which would also signal htsget, but be susceptible to the pathological case [discussed at the link]); or a case could be made that the point of htsget is to make requests for subsets of files and refuse to return the whole file by returning 426 instead. (We could define ?class=all to be an explicit htsget-style request for the whole file if that was useful.)

This PR dos not address that, but it could be added as a follow up if desired.