Don't throw in low level client

[acoburn]

This is an alternative to #1248

In conversation with @langsamu, we discussed how throwing an exception in the low-level client conflicts with the overall architecture of the JCL, and making that work (as in #1248) adds a lot of complexity to the very core of the client processing, which is the last place we want to add complexity.

This PR takes an alternative approach: here, any ProblemDetails structures exist only in the high-level (solid) client, which is the only place where exceptions get thrown.

This also means that the previously existing ofModel, etc, in the Jena and RDF4J modules are brought back to their original (non-deprecated) state.

In terms of commits, this reverts #1159, #1162 and #1184. The fourth commit reworks the implementation of ProblemDetails by relocating it to the solid module.

[NSeydoux]

With this approach, the Problem Details response will not be parsed from the Access Grant service for instance. Is it something we want to add in a subsequent PR, or are we choosing not to support this for the time being?

[acoburn]

With this approach, the Problem Details response will not be parsed from the Access Grant service for instance. Is it something we want to add in a subsequent PR, or are we choosing not to support this for the time being?

What I would suggest is that we make the ProblemDetails class into an interface, placing it in the API module. Then, there can be implementations in the solid module (as in this PR) and also in other modules, as needed

[acoburn]

@NSeydoux yours was a good suggestion and is implemented in b48c052. This will allow us to add a ProblemDetails implementation in the access-grant module.