Comply with table specs v1

[tcompa]

Refs:

• Comply with table-specs V1 #602
• Review use of write_table in registration tasks #594
• Update feature tables as per table specifications, in napari-workflows-wrapper task #593
• Review module/function structure for table-related helper functions #616
• Mismatch between table specs and implementation, re: instance_key column #617

Close #593
Close #594
Close #602
Close #616
Close #617

Checklist before merging

• I added an appropriate entry to CHANGELOG.md

[github-actions]

Coverage report

The coverage rate went from 90.48% to 90.74% ⬆️
The branch rate is 84%.

None of the new lines are part of the tested code. Therefore, there is no coverage data about them.

[jluethi]

I'm starting to review this PR. One thing I noticed:
The table .zattrs for our well_ROI_table & FOV_ROI_table don't have that "type": "roi_table", that the spec says they should have. Neither in the 3D Zarr nor in the 2D MIP Zarr.

[tcompa]

The table .zattrs for our well_ROI_table & FOV_ROI_table don't have that "type": "roi_table", that the spec says they should have. Neither in the 3D Zarr nor in the 2D MIP Zarr.

Thanks!
This is now tested with 73e4a87, and fixed with 1361c79.

The same fix is now needed at least within import_ome_zarr.

[tcompa]

The same fix is now needed at least within import_ome_zarr.

And in create-ome-zarr-multiplex

[tcompa]

The same fix is now needed at least within import_ome_zarr.

And in create-ome-zarr-multiplex

Both fixed with 62ddae0.

[jluethi]

This looks great, our table writing is becoming much more structured.

The PR does open a few questions for me though, I wonder whether we can address them here as well:
Are we expecting most users of the API to provide the attrs or is this a special case? Are we building up the correct attrs when users don't provide them? So far, we are doing this in the individual tasks, right? Should we document more in the docstrings of the table writer functions what valid attrs are that we expect (/where to find that info)?
The attrs are often optional parameters, but core info like table_type seems to be in them.

When are there potential conflicts between attrs & other parameters? (see also #619) What takes precedence?

My overarching question: Which parameters should be exposed as function parameters and what goes into attrs? And are those attrs really optional?

[jluethi]

Scenarios for type:

1. No type is provided (neither optional new arg, nor in attrs) => Fail
2. Type is provided with new arg => set the type in attrs to that new type
3. No type is provided in new arg, but it's in attrs => Fine

[jluethi]

Let's also tackle this one here: #619

[jluethi]

• _write_table_v1 should raise errors for masking ROI table or feature table if they don't follow the write attrs structure