Clarify how to store "additional information" for Points

Is your feature request related to a problem? Please describe.
The Design Doc for Points currently states:

Each observation is a point, and might have additional information (intensity etc.)

Thus, it seems that there are currently two ways to store additional information (i.e., additional columns besides X/Y/Z) for Points: as additional columns in the same Parquet dataframe, or as columns of an aligned (one .obs row per point) SpatialData Table element.

Further, it is unclear to me whether instance_key and feature_key refer to columns in the same Parquet table versus columns in a (point-annotating) SpatialData Table.

This may be confusing as a user creating SpatialData objects, or as a developer of a tool which needs to read/operate-on/visualize the points.

Describe the solution you'd like

• Clarify which table (Parquet table vs. SpatialData Table element) is meant to contain the columns referred to by the instance_key and feature_key metadata (if present)
• Option 1. Do not allow additional columns besides X/Y/Z(/instance_key/feature_key) in the Parquet table; Force any additional columns to be contained in a point-annotating SpatialData Table element.

Describe alternatives you've considered

• Option 2. Allow additional columns to be stored in either location, but clarify any limitations regarding the storage location choice (e.g., will all operations still work the same? will they have the same performance characteristics? when specifying a column name such as pointIntensity, how to specify to downstream software in which table to look for this column?)

Start with the Design Doc for Points and trace how the Parquet table and point-annotating SpatialData Table are described. Resolve where additional columns, instance_key, and feature_key belong, including any stated limitations for downstream operations. Done means the design documentation clearly identifies the storage location and how consumers should interpret these columns.