[FIX] add paragraph on MEG specific "markers" suffix in MEG spec

[sappelhoff]

closes #638 --> the *_markers suffix was only defined in the appendix and occurred quite unexpectedly and randomly.

• *_markers seems to only apply to KIT/Yokogawa/Ricoh
• This suffix was previously only defined in the appendix: https://bids-specification.readthedocs.io/en/latest/99-appendices/06-meg-file-formats.html#kityokogawaricoh

If we could turn back time we would probably solve the issue on "how to define KIT marker files" without adding a new suffix entirely for that issue.

I suggest this minor fix (this PR) to at least increase transparency of the "markers" suffix in the spec text.

For future enhancements it'd be cool if we could think of a way to somehow salvage the "markers" suffix in a backwards compatible way and put it to some use beyond KIT/Yokogawa/Ricoh. --> suggestions in that direction are very welcome.

The relevant part of the diff is this sentence (rest is typos, linebreaks, a link fix. and a historical perspective in the appendix):

+
+Another manufacturer-specific detail pertains to the KIT/Yokogawa/Ricoh sytem,
+which saves the MEG sensor coil positions in two separate files (`.sqd`, `.mrk`).
+For these files, the `markers` suffix MUST be used.
+For example: `sub-01_task-nback_markers.sqd`
+
Please refer to [Appendix VI](../99-appendices/06-meg-file-formats.md)
for general information on how to deal with such manufacturer specifics and to see more examples.

[effigies]

Overall looks good.

[hoechenberger]

Super late to the party, but why can we not name those marker files *_meg.sqd and *_meg.mrk, so we wouldn't need the markers suffix?

[sappelhoff]

Super late to the party, but why can we not name those marker files *_meg.sqd and *_meg.mrk, so we wouldn't need the markers suffix?

that would make sense to me, would be good to go that way.

We'd then still have to document and deprecate the markers suffix

[teonbrooks]

*_meg.sqd

this is the same name as the raw file so it would likely collide naming-wise

[hoechenberger]

this is the same name as the raw file so it would likely collide naming-wise

Oh, darn, I wasn't aware of this! Ok, in that case we cannot do this. Sorry about the confusion.

[teonbrooks]

it is a historical and inconsistent pattern that was introduced. here's a brief history from what I can recall:

the original extension for Ricoh continuous data was .sqd. This was later modernized to .con (to denote continuous I believe) but to preserve backwards compatibility .sqd is still valid and acceptable for the raw, continuous data file.

the original extension for Ricoh marker file was .sqd as well. To determine if it is continuous data or marker file, the internal header file specified this. This was later modernized to .mrk to disambiguate files but to preserve backwards compatibility, .sqd is acceptable.

[sappelhoff]

awesome, thanks for shedding some light on this @teonbrooks!