Simplify the Object/Display/DisplayViewer type hierarchies

[ctrueden]

In conjunction with imagej/imagej-common#12, we want to rework how SciJava Displays are structured.

The status quo:

• You have an Object, which gets wrapped in a (UI-agnostic) Display. Each Display is a list of such Objects, rather than only a single Object. To visualize that Display, you then need a UI-specific DisplayViewer, which actually shows the Display's contents to the user somehow.
• In ImageJ, the type hierarchies are more complex: you have a Data, which is wrapped in a DataView (e.g., Dataset wrapped in DatasetView, or Overlay wrapped in OverlayView). Then an ImageDisplay, which is a type of Display for DataViews.

We can streamline this. Let's have instead:

• View, which wraps an Object, and contains visualization settings. Subtypes of view (e.g., ImageView) implemented as needed to encapsulate the appropriate viz settings.
  • A ViewService handles wrapping of Objects to the most appropriate View.
  • In the case of images, there would be an ImageView which has a position (while its wrapped Dataset does not).
• Display, which becomes a UI-specific thing used by the UIService.
  • In other words: DisplayViewer gets renamed to Display.
  • The old Display no longer exists—we only support a single View per Display.
  • We have a DefaultView that is used for Objects with no particular need for visualization settings.
• To cover the need for multiple N-dimensional image objects (i.e., Datasets and Overlays) bagged together, we provide CompositeView, which composes a list of Views in a single composite space.
  • See also CombinedInterval et. al in imagej-common, which will facilitate this.
  • This CompositeView would be the closest thing to the current Display, but would support recursive nesting of Views, so that a proper object hierarchy can exist (see also Improve Display-DisplayView-Data hierarchy imagej/imagej-common#12).

These changes would reduce the amount of names floating around—we would no longer need "viewers" but would only have Views and Displays. It would also help simplify the implementation of new UIs, at least from the perspective of understanding the execution flow.

[ctrueden]

There is also the possibility of getting rid of View altogether. Display is UI-specific and operates on a particular type T. All viz settings (e.g., dimensional position of a Dataset) would need to then wrap into Dataset itself. While this would be a slightly worse separation of concerns, it would greatly simplify the architecture, to the point where I'm thinking it's worth it.

So if you want to show the same image with same visualizations settings and position, great—add the same Dataset to two different ImageDisplays or whatever.

And if you want to show the same image with different viz settings, we can have a by-reference Dataset wrapper that exposes different settings, but for the same backing data object.

Further thought needed of course, but my current thinking is "the fewer class hierarchies, the better".