WidgetModel: getChoices() can return null

... and indeed, the default implementation in AbstractModuleItem *does*
return null. Therefore, we should *never* expect it to return a list
in all cases, and exercise defensive programming instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a Module class for use with script input parameters

The easiest way to handle input parameters is really to have a Module and
pass it to the CommandService.

This is what we will do with scripts, too, so we need a special-purpose
Module whose only goal is to populate input parameters.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Support input parameters in scripts

With this change, the script service will parse the first few lines for
patterns of the form:

	@Class name

It will stop at the first line that contains at least one alphanumeric
character but no '@' character.

If any such input parameters are found, they will be populated via the
CommandService.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a proper JavaDoc for the Javascript test

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
JavascriptTest: simplify the code

Recent changes allow us to instantiate the SciJava context with a
given service interface.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
JavascriptTest: add a test for input parameters

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Script inputs: set a helpful dialog title

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Improve javadoc
Bump to pom-scijava 1.94

Signed-off-by: Jenkins <jenkins@dev.loci.wisc.edu>
Use new RichPlugin interface where appropriate

This is cleaner than the old SortablePlugin extension point (which was,
confusingly, an abstract class): interfaces which extend RichPlugin are
implemented by abstract base classes which extend AbstractRichPlugin,
which matches the pattern used everywhere else.
Main: revert ordering of args processing

There was a problem with --run not working before the UI has been shown,
so I swapped the order to do processArgs after showUI. Unfortunately,
that prevents the console arguments from affecting the behavior of
showUI (e.g., by setting which user interface actually gets activated).

Better to process the arguments first, *then* show the UI.
MenuService: remove hardcoded dependencies

Whenever possible, it is cleaner not to force a service interface
to depend on other service interfaces.
RunArgument: make --run behavior consistent

You can pass either a class name or a command title. But previously, the
class name version did not consume an options string as a third
argument. We now do so in both cases (and if there is no third argument,
we assume the empty string).
OpenArgument: do not force the UI to show anything

Rather, we simply create a display for the opened object. If the UI is
later shown, it now takes care of showing the display which was created.
And if not, no big deal.
AbstractUserInterface: don't show displays twice

If a display is already being shown, the show method just returns.

This may become a problem if we decide to support multiple simultaneous
UIs, but for now is better than the display popping up multiple times,
which was previously the case if you manually called
UIService.show(Object) followed by UIService.showUI().
DefaultUIService: remove warning if no viewer

We now use the getDisplayViewer method to determine whether a display is
already being shown in the UI. But this caused the warning to appear
every time a display was not currently being shown. It is not really an
invalid state for a display to have no viewer instance yet.
DefaultUIService: fix race condition in lazy init

I was lazy when converting services over to lazy initialization, in that
I did not handle multiple threads properly. It is not actually that hard
to do: just make a boolean state flag, synchronize the initialization
method, setting the state flag upon completion and returning early if
the flag is already tripped. In this way, if a bunch of threads all try
to call a service's methods at once and trigger multiple lazy
initialization calls, only one of them will actually do the work and the
others will block until initialization is complete.

This change fixes a race condition when launching ImageJ with the
"--run" argument.

We should replicate this pattern for the other lazily instantiated
services...
Add --ui command line argument
ImageJService: tweak style
Merge branch 'master' into script-parameters