Alternative SPARQL Update support

[kjetilk]

During the Solid Editors call 2021-10-20,  @timbl reiterated that it might be a good idea to have different syntax for different semantics rather than the consensus of #125. I decided to explore this further, also in light of the discussion in #322 and this pull request can be thought of as an alternative to #320, but it also builds on it.

In this PR, I have replaced DELETE with REMOVE and so, REMOVE carries semantics that enables error reporting. This PR is actually more complete than #320, as the latter was intended to be a minimal change to SPARQL. This PR departs more significantly, but also defines a MIME Type for the result.

[RubenVerborgh]

I don't feel comfortable supporting this idea, given that it means we cannot use an existing stack. As Solid, we should not reinvent the wheel, but rather leverage existing standards.

[kjetilk]

I appreciate this sentiment, but what we have to decide upon is how we define this in the short term that behaves approximately how it behaves in NSS (or where NSS can trivially be changed to it), i.e. for 0.9. I'm also trying to make sure we do not depart very far from SPARQL as defined, but the behavior in NSS is clearly not compatible with SPARQL, so in the short term, it is not an option to just leverage existing standards.

[RubenVerborgh]

how we define this in the short term

In the short term, it's even harder to write a custom parser.

It's not just how fast NSS can change (which uses a custom, incomplete, non-compatible parser), but how all implementations can change (in particular those using an off-the-shelf standard SPARQL parser).

[kjetilk]

Sure. In #322 , I wrote a comment about what I personally think is reasonable to add and what is not.

In the code that I've seen, it doesn't seem like it is not so much the parser, it is more the semantics of connecting the counting of solutions to a failure. You might end up with a horrible hack using a thrown and caught exception, or something.