Implement include query parameter

[CasperWA]

Closes #94

This PR also changes the API slightly, in the sense that it renames optimade/server/deps.py to optimade/server/query_params.py, as was first suggested in #162.

Note: Support for providing relationship paths to include is not implemented, only endpoint names/entry types, e.g., "references".

[CasperWA]

Should we include child, parent, etc. types in the "allowed" types to pass to the include parameter? Now it is the keys of optimade/server/routers/__init__.py:ENTRY_COLLECTIONS, i.e., links, references, and structures, as well as the "empty" values: "" and ''.

[CasperWA]

I started to play around with using a regex or Enum for include, but ended up not doing this, since if caught in the validation, it will respond with a 500 status code, but the spec specifically asks for a 400 status code response if the include does not validate properly.
This is handled further down the line in the code, so it will be left "open" in the query parameter classes.

[ml-evs]

This looks solid, thanks @CasperWA. Works nicely at my end.

[CasperWA]

What is your position on including other entry types, such as child and so on? Or should we just keep it for references and structures (and links)?

[ml-evs]

What is your position on including other entry types, such as child and so on? Or should we just keep it for references and structures (and links)?

I guess parent, child, and provider should all be allowed as they are valid types (if not entry types).

[CasperWA]

Hmm. Looking further into the code on how relationships are handled in general it's a bit messy. The models only allow references and structures at the moment, but the routers also allow links.
Furthermore, the JSON API infers resource types, not endpoints, but in OPTiMaDe we have decided to make it only endpoints (or is it types? - I am confused about that, although for references and structures it doesn't matter, since it's the same), and one can even supply nested relationships to include, which is not at all implemented in our repo. And I don't know exactly how we would do that either just now.
So I think I will just let the query parameter validate against what the router utility function is also validating against, i.e., links, references and structures. I wonder what happens if links is provided now?

[CasperWA]

(...) I wonder what happens if links is provided now?

It works fine with links, but that should only be true as long as noone actually starts adding links relationships to the data - since then the models shouldn't allow the relationships. Even though the router utility function technically is fine with it ...

Anyway, leaving the include parameter to validate against the same variable as the utility function handling included relationships seems the best approach now. And then it can be updated together at a later point.