Filter LDP containers and AS containers

If we don't always provide a SPARQL endpoint to SemApps instances, it would be important to at least be able to filter LDP containers (and AS collections !), which is where SPARQL is the most relevant. The `ldp.container.get` action already accept a `filter` param, but it is not available on the API.

We have several options:

## With a ShEx shape

Pass a SHACL/ShEx shape when GETting a LDP container, so that only resources matching the shape are returned.

Sarven comment:

> Interesting. Typically GET is not used that way, i.e., passing a URI for the server to use / look-up. I can imagine that might be a security issue for a server, especially if they're to use anything unknown. But then again, even things like HTTP signatures have a pubkey that can be a URI... so I don't know entirely where things stand out there.
> Could you dig into if/what the SHACL WG may have discussed on this matter? That could be useful input for us.
> Alternatively, POST can be used since the payload would give the instructions to process something, but that's not particularly what you are looking into either.. as you seem to want a subset of some information from a resource. Which is why I thought of the Prefer header.
> I think a SPARQL query may be most fit for the purpose.

https://www.w3.org/TR/ldp/#prefer-parameters
https://www.w3.org/TR/ldp/#prefer-examples
https://www.w3.org/TR/ldn/#constraints
https://solidproject.org/ED/protocol#constraints-problem-details

Would require some kind of Shape-to-SPARQL converter
- Exist for SHACL: https://shacl-play.sparna.fr/play/sparql

## With a SPARQL query

Unfortunately there seems to be no spec available to do a SPARQL query only on a single resource or container. Libraries like Communica allow it, but they fetch the resource/container, and then apply the SPARQL query. What we would need is to do that on the server side.

## With Linked Data Fragments

The Linked Data Fragments server is too heavy for this use case, and we would need to develop a WAC extension like we did for Fuseki. But we could use the LDF spec to query the container itself.

See https://linkeddatafragments.org/specification/triple-pattern-fragments/#http-based-implementation

## With a custom Header or query string

If all other solutions fail, we can always use a custom header or query string.

## Related issues

- https://github.com/assemblee-virtuelle/semapps/issues/235

Start with the ldp.container.get action and the API path that exposes it, then review the LDP Prefer and constraints references and related issue #235. Compare the SHACL/ShEx, SPARQL, Linked Data Fragments, and custom-header/query-string options; done means agreeing on a concrete filtering approach and its API behavior.

Written by the indexing model from the issue text.