Adding the property_ranges query parameter and associated metadata

[JPBergsma]

This PR describes how a client can request a specific part of a property that is returned as partial data.
I have tried to keep things as much as possible the same as in the original ranged properties proposal #452.

[rartino]

Thanks for writing this up!

Why did you move the whole section "Transmission of large property values"? It makes it tricky to see what has changed. Can you move it back?

Also, my interpretation of the workshop discussions was to make the property_ranges query parameter completely separate from, and orthogonal to, the mechanism for "Transmission of large property values" (this was a strong point of @sauliusg). Hence, it isn't clear to me why anything has to change in the "Transmission of large property values". Why can't we keep all documentation about this feature in the definition of the property_ranges query parameter?

[JPBergsma]

It seemed more logical to place the metadata section before the "Transmission of large property values" section, as the "Transmission of large property values" section depends on the metadata section but not the other way round. So it is more useful to read the metadata section before the "Transmission of large property values" section.

[JPBergsma]

You are right, I could still separate the property ranges query parameter and the extra metadata fields from the transmission of large data section, as each could still be used separate from the other. I'll try to do this next week.

[JPBergsma]

To clarify why I moved this section:

The section "Transmission of large property values" uses features from the section "Metadata properties". But the section "Metadata properties" does not depend on the section "Transmission of large property values" so I therefore placed the "Transmission of large property values" after the "Metadata properties" section.

I have made two small changes in the "Transmission of large property values" section:

Line 534 I replaced "one of alternative partial data formats " to "one of the partial data formats".
As I do not think the word alternative adds anything here.
Line 537: I broke the sentence into two parts and replaced "from the response, with three different links" with "from the response and includes three different links"

[ml-evs]

Mostly formatting changes and suggesting rewordings -- I think I can go through and force most of them in if there are no objections

[rartino]

This PR appears a bit stalled and is important. @JPBergsma do you plan to continue working on this, or are you ok with me (or someone else) starting to merge changes into it?

[rartino]

This PR makes a number of references to "range_ids", which is not the term used in the property definition PR #445. This needs to be adjusted.

[merkys]

Suggested change

	The outermost dimension of a nested array should come first.
	The outermost dimension of a nested array MUST come first.

I think making this a MUST would make it easier to use both for client and server.

[merkys]

Suggested change

	If, within one entry, dimensions for two or more properties share the same :field:`range_id` those dimensions should be thought of as the same dimension.
	If, within one entry, dimensions for two or more properties share the same :field:`range_id` those dimensions should be treated as the same dimension.

[merkys]

Suggested change

	For example, if both the :property:`energy` and :property:`cartesian_site_positions` of a molecular dynamics trajectory share a range_id of :val:`frames`.
	For example, both the :property:`energy` and :property:`cartesian_site_positions` of a molecular dynamics trajectory may share a `:field:range_id` of :val:`frames`.