Consider whether we really need this component

It would be slicker, if instead of writing `ij.notebook().display(image)`, we could simply write `ij.ui().show(image)` and it would do the right thing.

For that to happen, though, the SciJava Common `UIService` would need to be updated so that the `show` returns `Object` instead of `void`. We could certainly do that for SJC3.

Then, we could have a `BeakerUI` which checks for some Beaker-only state (e.g., the system property `sun.java.command` starting with `com.twosigma.beaker`) and enables itself preferentially in that case. We may need to enhance the `UserInterface` selection to accommodate such contingent activation, though.

We could similarly have a `JupyterUI` which activates only when inside a Jupyter notebook. And then both of these UIs could override `show` to return the correct thing.

This would be much cleaner than the current approach of a dedicated `imagej-notebook` component.

The `HeadlessUI` could then even call the ops `image.ascii` routine and log the result when `show` is called.

Start by reading the SciJava Common UIService and UserInterface APIs, then inspect the current imagej-notebook component that provides ij.notebook().display(image). Compare the proposed BeakerUI, JupyterUI, and HeadlessUI activation paths. Done requires an agreed design for contingent UI selection and show return values; the issue does not name files or tests.

Written by the indexing model from the issue text.