Formalize "IndexColumns" for .tsv files

[yarikoptic]

Eric: I would rather explicitly define the index columns in the JSON header

Yarik: Please propose it as an alternative proposal to this one then! We might then consider them one by side later.

Here's an example:

{
    "IndexColumns": [
        "participant_id",
        "session_id",
        "run_id"
    ],
    "participant_id": {
        ...
    },
    ...
    (all the other usual data dictionary sidecar JSON stuff)
    ...
}

Originally posted by @ericearl in #2273

So proposed as an alternative to

• Formalize joint index support in .tsv via {"+".join(entities)}s.tsv files #2273

[yarikoptic]

Overall I like "explicit better than implicit" aspect of such an approach! But immediate cons with my assessment of severity

• (major) inability to separate common (e.g. across sessions and runs in the given example) metadata into its own file, and thus encouraging duplication, and duplication is evil and avoidance of duplication is inherent to the foundational "Inheritance principle" strategy of summarization of common metadata at higher level(s)
• (medium) breaks software compatibility which can load current .tsv files under assumption of a singular index (and thus unique rows e.g. per participant_id)
• (low) adds to the mix of columns description entries and now a new "control metadata" (IndexColumns, I guess complement to Columns of .tsv.gz) and that is in addition to other potential metadata we already allow/expect in some cases (ref: Uniformize .tsv and .tsv.gz: both to have header + both have "Columns" dictionary (!not list) in sidecar .json  bids-2-devel#71; so hopefully would not be an issue in bids 2.0)
• (medium) while we already have sessions.tsv etc, nothing in the name of participants.tsv would suggest that it is a file with content potentially with metadata across participants+sessions+runs. And the point of BIDS is to provide filenames descriptive to humans! (otherwise we could have just gone into collection of UUID based folders + index table) , and complimentary for machines:
• (low) it would require loading .json file to be able to answer if we have a joint index for any operation on .tsv

note that IMHO my proposal in #2273 does not have any of those cons.