SPARQL protocol support

[dennisvang]

The current /search/sparql endpoint only supports POST of application/json data.
In addition, the content-type for the response is limited.

To improve utility, it may be good to provide (read-only) support of the SPARQL protocol.

That would mean, among other things:

• GET with query parameters
• POST consuming (instead of application/json):
  • application/x-www-form-urlencoded and
  • application/sparql-query (unencoded body)
• content negotiation for a variety of types

See SPARQL protocol for details.

This would basically be a replacement for the full-sparql query endpoint described in #852 and implemented in #853. This endpoint did allow full SPARQL queries, but the requirements did not explicitly include compliance with the SPARQL protocol.

[dennisvang]

A proxying solution would have my preference, but what to do with the in-memory and native triple store modes?

[dennisvang]

Even creating a proxy endpoint is complicated by #824. For example, due to the vendor specific configuration, there's no simple way to extract the repository url. We cannot simply use HttpRepository.getRepositoryUrl() nor can we use SparqlRepository.toString() to get the queryEndpointUrl directly. Instead, we need to add logic to determine the type of repository first, or build the url manually from the vendor-specific config.