Store::SPARQL reads and writes to Virtuoso (>=6.1.7)

We're probably going to have to chat about this one:

1. I had to add some ugly state maintenance Test::RDF::Trine::Store because I couldn't guarantee an empty store to test context-less semantics. The tests seem to work on the ones that I tried, but I don't have all the backends.
2. Virtuoso doesn't respect `q=` values in the `Accept:` header, which made response handling complicated. At the moment it's hard-coded to JSON because V does some stupid, stupid behaviour otherwise.
3. The net effect is that robust, product-independent HTTP response handling will be very, very complicated. I stubbed out a provision for handling different products, but I have more pressing things to do than fill that all out.

Otherwise, it works.
Oh. Right. I did something to `get_statements` a while back that made it possible to do stuff like:

```
my $iter = $foo->get_statements(undef, [$p1, $p2, $p3], undef);
```

The reason for that was because the store was the rightful place to do any optimizations around data transactions.

When I was writing Store::DBIC, I found that there was a significant penalty (~30 msec) for each fetch from the database, so I wanted a way to double them up. This was before I understood what `get_pattern` was all about.

However, I submit that after looking at the implementation of `get_pattern`, I'd be inclined to architect it such that it translates to this form of `get_statements`, thus guaranteeing the minimum number of calls to the store for the desired data.

I understand that's a little more than bargained for, and I'm content to drag out the changes to RDF::Trine::Model (which are non-destructive) that permit this behaviour. I also recognize that changing the individual storage drivers to accommodate this behaviour amounts to additional work, but I'd be happy to help flesh that out.