Define OPTIMADE regex format

[rartino]

We keep coming back to the lack of regex:es in the OPTIMADE specification, in particular lately:

• In the pattern validation for OPTIMADE property definitions (see Add ECMA definition of symmetry operation regexp and associated tests #488)
• In the more advanced string search operator Like operator #160.

The challenges with picking one specific regex format has been debated quite intensely all the way back to, e.g., #42, for more recent discussions see far down in #160.

This PR creates a free-standing appendix that describes what I believe works as a regex format for OPTIMADE (see in particular the discussions far down in #160 to see the motivations for this particular format).
No parts of the specification itself yet refers to this appendix. This is intended to be added in #488 and #160.

It would be desirable to merge this fairly soon since it appears we have painted ourselves into a corner to a degree with regards to the need for the pattern JSON Schema validation field to properly validate the new space_group_symmetry_operations_xyz property.

[ml-evs]

I'm not sure I see the need to couple the regexp format for search (e.g., a future LIKE) and the JSON Schema field pattern for constraining the shape of allowed values of fields (and in our only example so far, a field where we explicitly state that search is not recommended), so for me the only thing missing is to simply allow pattern in our property definitions. Perhaps this comes down to me not seeing a use case for the suggested LIKE operator given the current use of string fields though.

[rartino]

@ml-evs

I'm not sure I see the need to couple the regexp format for search (e.g., a future LIKE) and the JSON Schema field pattern for constraining the shape of allowed values of fields

We now have (at least) two different places in the specification for regex:es where we intend to standardize on subsets of PCRE2 so that not all implementations are forced to handle the full complexity of all of PCRE2 (or possibly worse, the specific ECMA-262 flavor of it, which may not even be 100% compatibly supported by the PCRE2 library in a few years). Does it not make sense to make these regex formats exactly the same?

I suppose a property validator usually can be written with access to the full PCRE2 library. However, one may want to give a bit of consideration to the possibility of validating other data formats against these schemas - in which case it would be nice, e.g., if the pattern property definition regex is restrained enough to be translatable into, e.g., an XML Schema regex, etc.

[rartino]

@sauliusg You are the author of #160 for better string search in the filter language, which presently sits at us agreeing to skip "LIKE" and do a "MATCH" operator for a subset of PCRE2, with is what this appendix is trying to make precise.

Can you please take a look at this quite short PR and say if you agree this is a useful appendix to standardize the right regex format for OPTIMADE filters? (The idea is that #160 can be updated to refer to this appendix once it has been merged).

Note that I've left out range quantifiers ({x}, {x,y}, {x,}). I do not feel strongly about that, I just have a gut feeling that there are db backends and schema languages that do not do them. If anyone speaks up feeling strongly to include them, I'll change that. I have a slightly stronger opinion to omit the lazy matching given support in current db backends (this I believe was pointed out by @sauliusg somewhere in the discussions about #160).

[ml-evs]

Only one formatting issue, otherwise good for me

[sauliusg]

After diffing commits fb2e2d3 and cba1227...