Prevent the LegacyInitializer from being called recursively

The SwitchToModernTest exposes the problem where the legacy initializer
creates a new context that in turn tries to create a new legacy service
which creates a legacy UI which in turn triggers the initializer to be
run. Break the loop.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Help diagnose multiple contexts

For the moment, there can only be one LegacyService per class loader.
Let's make sure that we're giving enough information to diagnose what
went wrong when a second legacy services was about to be instantiated
nevertheless.

While at it, make sure that resetting the current instance is guarded
in a synchronized block just like setting it is.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
SwitchToModernTest: make *extra* sure that there is an annotation index

When building in Eclipse and running the SwitchToModernTest first thing,
for various reasons the annotation index is not built correctly. So
let's just run it in every case, even if we *know* that we're running
inside Maven.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Show UI for legacy editor test drive

This is required to auto-generate a dialog for input parameters.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
IJ1Helper: only set main window title and icon if there is a main window

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
IJ1Helper: be more careful when adding menu items

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Invert the LegacyCompatibleCommand logic

Instead of having to mark commands that are legacy-compatible, we now
require that commands that want to be marked as legacy-incompatible
*explicitly* by adding a 'no-legacy' attr.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
IJ1Helper: Allow modern commands to override legacy ones

Unless a command is marked explicitly with a 'no-legacy' Attr, it
should be allowed to override existing legacy commands.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Remove the LegacyCompatibleCommand

It is no longer needed.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Remove the legacy-compatible editor plugin

We just inverted the logic with regards to legacy-compatible commands:
instead of marking the compatible ones, we require the "no-legacy" attr
in the @Plugin annotation for the *incompatible* ones instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge branch 'compatible-commands'

This topic branch inverts the logic regarding commands that are
compatible with the LegacyUI (read: commands that want to override
legacy commands as opposed to commands that do *not* want to do
that).

While previously, we followed the approach that each and every
legacy-compatible command needed to implement the
LegacyCompatibleCommand (or have an overriding subclass that implements
it). This turned out to be problematic: for every compatible command,
we would need to add the respective dependency to imagej-legacy and
subclass the command.

Instead, we now require every *incompatible* command to add the

	attr = { @Attr(name = "no-legacy") }

setting to their @Plugin annotation.

We marked all the commands in scijava-plugins-commands, scijava-ui-swing,
imagej-common and imagej-plugins-commands which clashed with legacy
commands as legacy-incompatible using above-mentioned @Attr. This is
most likely too broad, but at least the behavior does not change for
now: legacy commands are not overridden by modern commands until they
are considered robust even in conjunction with the legacy layer.

The tests as of the time of writing are throwing non-fatal exceptions;
these are caused by a plugin in imagej-common that has been fixed in the
meantime (if the exceptions bother you, run the tests with
-Dimagej-common.version=0.6.0-SNAPSHOT).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>