SpatialData multitable support

[ckmah]

The sdata.table accessor is deprecated as of spatialdata v0.1.0 to make way for multi-table support. Refactor with new API. Do you have any advice going forward @LucaMarconato ? 🙏

I'm wondering if it is safe to assume default table name is just "table", in which case I will try replacing all instances of sdata.table with sdata.tables['table'].

[LucaMarconato]

The default table name is assumed to be table. Default in the sense that when some APIs, like aggregate() or get_values() are requiring to specify a table name, table will be used. But users will now be required to name their table when constructing their objects, and they could choose any name.

To support multiple tables I would consider the following: 1) the change is backward compatible: with all the previous datasets, sdata.table is equivalent to sdata.tables.get('table') (but you can probably just use sdata.tables['table'] or sdata['table']; using these two shorter syntaxes the code reacts differently if the table is not there). 2) before the assumption was "there are multiple elements, some of them may be annotated by a table". This is still valid, you just have to retrieve which is the table name, which can be done using the function spatialdata._core.query.relational_query._get_element_annotators(). We should make this function public, I didn't remember it was private, I'll open an issue on this (cc @melonora).

So the changes should be minimal and easy to implement.

[melonora]

Completed with #596

[ckmah]

I see thank you! Note to self, check table creation instances as well as table accession calls.