Add the script interpreter plugin

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a 'test drive' for the script interpreter

This makes it easier to debug and improve.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Default to 80 columns in the ScriptInterpreter prompt

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make the ScriptInterpreter prettier

While at it, output to a scroll pane (d'oh...).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
InterpreterWindow: make some fields local

No need to keep a private instance field if it isn't going to be used.
Remove serialVersionUID fields

This field is only needed for classes intended to be serialized.
Otherwise, it just clutters the code.

The recommended ImageJ Eclipse configuration suppresses any warnings
about this field.
InterpreterWindow: set frame title
Prompt: make private methods private

See:
http://imagej.net/Coding_style#Private_over_protected_fields_and_methods
InterpreterWindow: use narrowest type available

There is no point in widening the variable type of a private field.
Prompt: pass the interpreter instead of the window

This is more direct, because all the Prompt needs from the
InterpreterWindow is its ScriptInterpreter.

It also paves the way for an imminent restructuring of the UI.
Add a class encapsulating UI for an interpreter

Each ScriptLanguage has a ScriptInterpreter,
which is wrapped in an IntepreterPane.
InterpreterWindow: make each language a tab

This is much simpler than trying to keep track of an "active" language,
shuffling things around, etc. In this way, all the available languages
are accessible from a single click. It is unlikely the number of
available scripting languages will grow too large to accommodate this
style of UI.

This also keeps the UI simple, eliminating the need for MigLayout.
Do not force the prompt to be too wide

The number of columns effects the minimum width. And we want the minimum
to be small; the prompt will grow in width to accommodate a wide window.
InterpreterPane: use same size as old interpreter

The old interpreter was nice and compact, and what people are used to.
Let's use that same size with the new interpreter, too.
Prompt: support multi-line input with shift+enter

It is nice to be able to enter multi-line commands by pressing
shift+enter to defer execution of the command. The old interpreter
supported this, so let's support it here also.
Make the prompt a little taller by default

It looks too squished with only one line. Three lines is more inviting.
Give all extra resize space to the output pane

If the user wants the prompt to get bigger,
it can be enlarged using the split pane gripper.
InterpreterWindow: sort language tabs by name
Echo command to the prompt in the output window

The old interpreters echoed the command. And it is nice to see the
confirmation that indeed the system knows you pressed enter, and it is
executing stuff. Otherwise, for many commands, the prompt just clears
and there is no friendly indication that anything else happened.
InterpreterWindow: use context injection

Rather than passing a hardcoded list of services, let's declare them
using @Parameter. That way, when we inevitably need new services in the
future, we do not have to change the API contract in order to pass them
to the constructor, but can instead declare them as new instance fields.

What new services will we need? Well, the PrefService for starters,
since we'll need to persist the interpreter history and active tab
settings.