Consider which objects to register with the ObjectService

Right now, any `Data` objects get stored in the `ObjectService` as long as their reference count (number of things displaying them, essentially) is > 0. And when the ref count hits zero, they are removed from the `ObjectService`. This is because the `ObjectService` keeps hard references.

We could:
- Add a feature to the `ObjectService` to support weak or phantom references. This can eat memory though and delay garbage collection of otherwise-obsolete data.
- Consider making more things extend `Data`, particularly `Table` implementations, which would be nice to have a multiple-choice selection for when they are used as inputs.
- Generalize the reference counting thing beyond `Data` if needed.
- Forget all this reference counting stuff, and enhance the ObjectWidget to look for `Display` objects in the `ObjectService` that are currently displaying the needed type—and populate the multiple choices with those objects.

That last option is how I'm currently leaning, without having thought or investigated thoroughly enough to be sure I'm remembering how everything works 100% correctly. Would need to be sure things still work headless, though, if nothing is being displayed.

No files or tests are named. Start by tracing ObjectService, Data, Table implementations, and ObjectWidget to understand registration and display lookup, then check how the behavior works headlessly. Done means agreeing on one registration approach and defining its behavior for displayed and undisplayed objects.

Written by the indexing model from the issue text.