[REF] Consistently reference object keys in rules

[tsalo]

This PR proposes that we use object keys (i.e., the unique keys of the dictionaries in the object schema files) as our primary object identifiers in the rule schema files. At the moment, we use a mixture of keys and fields within the object definitions, depending on the object type.

Suffixes and extensions are referenced using their object definitions' "value" field, while most (all?) other object types are referenced using the object keys.

Why we might want to make the change

• It is more consistent to use the same identifier for all object types.
• It would not be difficult to update our code to use object keys instead of a range of different fields.
• The current system assumes that no extensions or suffixes will ever be overloaded (i.e., have more than one meaning). However, if, for some reason, we do need to overload an extension (e.g., two BEPs use established formats with the same extension), then we would need to reference unique identifiers like the keys.

Why we might not want to make the change

• Using the unique object keys for some fields (i.e., extensions and suffixes) will be confusing for contributors. Suffixes and extensions are usually more interpretable in their literal form (e.g., .nii.gz instead of niigz or "Gzipped NIFTI"), and we try to ensure that neither object type is overloaded.
  • The steering group and maintainers have ensured that it is essentially a rule that certain objects cannot be overloaded, including suffixes. We can recommend against using existing extensions for different file formats, but there are some extreme edge cases where that could be impossible, such as adding in new modalities that use the same extension for different, well-established file formats.

Changes proposed:

• Replace extension values with extension keys in the rules files.
  • For example, the key for TSV files is "tsv", while the value is ".tsv".
• Replace suffix values with suffix keys in the rules files.

[tsalo]

@TheChymera it looks like a bunch of validator tests are now failing, probably because of the changes I made to the rules files.

[tsalo]

One limitation of the test is that it doesn't recursively look through subfolders, so the derivatives folders are not being tested.

Also, labelgii and dlabelnii aren't defined in objects/extensions.yaml yet.

[TheChymera]

@tsalo so this is an easy fix, which would just need to go deeper in the nested dictionary structure after this line. I can fix it, but I still don't think this extension reorganization is a good idea.... If I'm the only one, we can go ahead, but maybe explicitly asking for comments somehow would be warranted. This just adds imho unnecessary higher-level categorizations which will make schema editing more intransparent and enable all sorts of exciting discussions about how we divvy up strings/regexes among these abstraction categories.

[TheChymera]

can we maybe not do this? =^.^=

see #1203 (comment)

[tsalo]

I mean, I still think we should, but it's up to the maintainers/steering group now.