[SQL/MEG] Add the MEG CTF head shape tables

[MaximeBICMTL]

Description

The MEG CTF format uses a headshape.pos file to register the head shape of the participant. This file is CTF-specific but BIDS-standard (the BIDS MEG specification basically allows to use native files of all specific data types), and is usually shared across all the MEG acquisitions of a session.

This PR adds some tables to register this data in the LORIS physiological database and link it to the relevant MEG files.

The headshape.pos file format is unfortunately very sparsely documented. It is a textual file format whose contents looks like this:

85
1		5.60644227	-6.38055462	0.79194871
2		8.06310971	-4.72750212	0.59046631
3		7.58675759	-5.78050209	3.05185917
...
NAS	8.57169649	-0.14219376	-3.33998151
LPA	-0.58286578	7.02263278	0.27529669
RPA	-1.40471662	-7.10183109	0.57320080

The first line is the number of points. The coordinates are in centimeters. It might be useful to use a proper physiological_coord_system in the future, but this can easily be added later IMO, so I'd like to start by merging this minimal implementation.

Testing

• ✅ Ran the SQL patch on Raisinbread.
• ✅ Use these tables in my BIDS MEG import LORIS Python branch.

[jeffersoncasimir]

Missing change to RB_physiological_file.sql. Would be a good idea to include the files for the 2 new tables in RB_files/, even if you leave them empty for now (many such examples in that folder).

Where does the meg_ctf_head_shape_file.FilePath typically point to? A centralized location or within a particular project's BIDS structure? If the latter, it becomes odd if one project references another project, if they share the same hash.

[MaximeBICMTL]

@jeffersoncasimir added the Raisinbread SQL, good catch!

Regarding FilePath, it points to a file within the LORIS BIDS directories (bids_imports/blablabla/sub-ABC/ses-DEF/meg/sub-ABC_ses-ABC_headshape.pos). I generally do not expect to have hash collision across projects as the coordinates in the head shape files are very precise and vary from participant to participant. Nevertheless, I think it is still a good practice to register the hash of files, if only to check that the files present on the file system match those registered in the database.

[jeffersoncasimir]

LGTM! I was concerned about it being used for duplication detection, as I've seen it used in some MRI pipelines. I can imagine a few scenarios where participant data could be, even unknowingly, re-ingested in another project.

I really like the idea of saving the hash of all ingested files. It's not currently the case everywhere