OPTIMADE JSON Lines specification appendix

[ml-evs]

This PR begins the work on #471, by defining the conventions on top of JSON Lines for deserializing an entire OPTIMADE API into a file.

[eimrek]

Thanks @ml-evs, and sorry for the delays. Now had some time to take a look. I like the proposal and it can be used for optimade-maker as well. But I wrote some comments for consideration.

[ml-evs]

CI is blocked by #536, but perhaps you could take another look when you get a chance @eimrek? I'll invite some other reviewers too.

[rartino]

Looks good; and as we said during the web meet, very important extension.

However, how are relationships encoded? Maybe it would be nice if the example included a structure that has a relationship to a reference so one can see explicitly how that is encoded?

[ml-evs]

An additional question about custom prefixes, that is (still) not clear to me, is what should happen when provider1 creates a JSONL file, and provider2 subsequently serves this.

Should all _provider1 prefixes be replaced by _provider2?

or would _provider1 prefixes be retained and this would fall under 3.5.2?

I think "serving" is an entirely different thing; provider2 should decide whether to re-host the properties with their own prefix, or point to the provider1 definition if it is available. It's a bit tricky to write this out (also somewhat addressed by d2c095a) -- somehow there are properties that are going to be namespace scoped to just the file in question as the file is the "provider". They can then be served with any prefix as long as they are consistent.

[ml-evs]

Thanks for the comments @eimrek, @merkys and @rartino -- I think I've clarified them now so this should be ready to go again.

[merkys]

I have no objections for this to be merged. I have myself encountered a need to store database subsets in OPTIMADE format, and this format seems to be just what I need.