move SparqlHttpModule to another project

[bblfish]

The SparqlHttpModule is only used by Jena, and is a blocking call over HTTP which is pretty much an anti-pattern in a reactive world.

trait SparqlHttpModule extends RDFModule {
  import java.net.URL
  implicit val sparqlHttp: SparqlEngine[Rdf, Try, URL]
}

The Sparql Engine implemented here is:

class JenaSparqlHttpEngine(implicit ops: RDFOps[Jena])
    extends SparqlEngine[Jena, Try, URL] with SparqlUpdate[Jena, Try, URL] {
...
 def executeConstruct(endpoint: URL, query: Jena#ConstructQuery, bindings: Map[String, Jena#Node]): Try[Jena#Graph] = {...}
...
}

Which means that any code calling this will block until the result comes back.

If the underlying code were able to work through callbacks, allowing a few threads to do the fetching and parsing of results, that would allow the above api to be Future based, which would be a very big improvement.

But even then there would be additional things needed for a good cross-implementation api such as: unified error classes, etc... all of which indicates that such a function should really belong in its own package.

So even though this mirrors the way Jena does things, it looks bad in banana-rdf. Given that this is only implemented by the Jena implementation it can also be confusing...

So it is ok to have this here as a reminder that something better needs to be done. Therefore I recommend that these classes and vals be deprecated with a comment linking to this issue, as that may stir people to come up with better answers, and also be prepared for this to be removed in the longer term.