Feature Proposal: Related Segment Properties

Segment properties are fantastic for discovery and curation of data, but limited to one particular view of the data at a time.

One thing that could make it much more powerful is a notion of "Related Segment Properties" or put another way, dynamically loaded but otherwise precomputed segment-specific segment properties. For connectomics, the most obvious use case would be a connectivity table for a selected cell, with segment properties that specify connectivity partners, carrying numerical values like input/output synapse count or net synapse size as well as potentially partner cell types, etc. Other use cases are easy to imagine as well.

The implementation could be extremely similar to the current segment properties using the same format and interface, but with a data type called something else, perhaps `neuroglancer_related_segment_properties`. The main difference for this type would be that the segment property would not reference a single JSON info file, but a directory of JSON info files indexed by segment id. In order to specify which ID to use to request an info JSON, the current "selection" widget already offers a mechanism for specifying at most a single segment id in a given layer, and thus it would be a natural fit for being the source of the ID to request. For example, if your related segment properties cloudpath is `precomputed://gs://my-data-bucket/connectivity`, Neuroglancer would find a root level info file specifying this new Related Segment Properties type and then look to `gs://my-data-bucket/connectivity/` to retrieve the complete Segment Properties info file associated with a selected id `seg_id` in that layer. The id-specific segment properties file would have a format identical to current segment properties (except for the `@type`). The root-level info file should contain the columns and tags to expect in order to make the interface consistent across individual entries. Perhaps the root-level info could represent a default state in the absence of a selection and could either be left empty or have contents that aid with data discoverability.

Duplication at the schema-level between individual IDs seems acceptable if not preferred, with the expectation that entries under the same directory follow the same schema to smooth the user experience.
Another nice to have would be if the UI remained consistent when new data is loaded. For example, if you are sorting or filtering by some numerical value like synapse count, the sorting would remain consistent even when you loaded data for a new segment id.