type and storage of `instance_key` issues

This is to keep track of issues that might arise on the relationship between instance_key and the indexes of regions.

Motivation

The link between a table and it's region object is specified by the tuple ("region", "region_key") saved in table.uns["spatialdata_attrs"]. The types are the following

• region: Union[str, Sequence[str]]. It can contain a single region id or a sequence of region ids
• region_key: Optional[str]. In case of a single region_id, then it can be None

To link the single region instance, e.g. the cell, an additional key is passed:

• instance_key: Sequence[str, float, int]

Problems

• We don't check for the consistency of this mapping in spatial data, e.g.:
  • are all regions present in the table, may/should/must be in the Spatialdata? we are not clear about this
  • is the type of instance_key matching the type of the index/region in the respective element? e.g. for labels,, it should just be int32 or int64, whereas for shapes, it could be str or numeric.
• we are not clear nor consistent on the way we name the regions and elements in the spatialdata_attrs

another thing to consider is that the instance_key can be just he index in a Shapes element, but it can never be an index in table.obs, because we can only have str and numeric indexes in anndata. This is also something we should be clearer about.

Start by reviewing the spatialdata_attrs relationship between tables, regions, elements, and instance_key, including the region and element index types described here. Before implementation, resolve which mappings are required and how names and index types should be represented; done should include consistent validation and documented behavior for tables, labels, and shapes.