Advanced search in the internal collections

Not to be confused with #140, which queries in external data sources.

This is a long-term design for internal search, mostly based on our discussion on February 21. I filled in some details which are still open to discussion.

- [ ] The client should contain a GUI for composing queries, which should include at least the following capabilities:

- [ ] Filtering by all biographical and bibliographical fields described in the EDPOP record ontology.
- [ ] AND/OR/NOT combinators for filters, ideally with support for recursion.
- [ ] A way to select which collections should be filtered. Querying multiple collections at the same time is an explicit goal here.
- [ ] A sorting criterion, including as options at least all biographical and bibliographical fields.

- [ ] Everything the user enters into this GUI is represented in a JSON-based model. The model is rich enough to fully reconstruct the state of the GUI.
- [ ] Besides the GUI-controlled settings above, the representation must also include an offset and limit in order to control pagination.

- [ ] The client sends the JSON representation to a backend endpoint.
- [ ] At the user's option, the JSON representation may be stored for later retrieval.
- [ ] The backend endpoint compiles the JSON representation to SPARQL, adding authorization-related aspects (i.e., in order to mask data that the user is not supposed to see).
- [ ] The SPARQL query is sent to the triplestore in order to retrieve all records matching the criteria.
- [ ] The results are sent back to the client, which renders them in a list.