ScriptInfo: tweak javadoc
ScriptInfo: fix position of instance field
ScriptInfo: make helper method private
ScriptInfo: remove unused method
ScriptInfo: allow inputs to be reparsed

This is useful if the source file has changed
(e.g., if it was edited in the Script Editor).
ScriptInfo: tweak ctor parameter order

We are going to add another constructor in a minute here, with a third
parameter, that "sort of" goes along with the "String path". To keep
those two next to each other, and to have the third parameter be third,
let's make the unrelated parameter (the Context) the first one.
ScriptInfo: add support for arbitrary Readers

There is now a constructor which allows passing a String (pseudo-)path
along with a Reader that provides the contents of the script. If a
Reader is given, that is used to parse inputs; if not, it is assumed
that the given path is an actual file on disk from which the contents
should be read.

It will typically be the case that ImageJ will discover scripts on disk
and wrap them in ScriptInfo instances using the File constructor. Such
scripts are the ones that will be managed by the ScriptService.

But running a script dynamically (e.g., from the Script Editor before
it is even saved) will be feasible by creating a new ScriptInfo object
which wraps the buffer itself in Reader form.
ScriptFinder: tweak ScriptInfo creation
Fix isCompiledLanguage API

It is now part of the ScriptLanguage plugin type, so that each
individual scripting language can extensibly override it.

The ScriptService#isCompiledLanguage(ScriptLanguage) method is gone.

This change also flags the JavaScriptLanguage as a compiled language,
as you might expect.
Remove obsolete exception class
ImageJPlugin: move to toplevel imagej package

This move is in preparation for the elimination of the imagej.plugin
package, which has really just become about module pre- and
post-processing at this point. This move also mirrors SCIFIO, whose
SCIFIOPlugin is in the base io.scif package, too.
Move module processing plugins to subpackage

This renames the imagej.plugin package to imagej.module.process.
It also moves the imagej.module.Module*Processor classes into
imagej.module.process, as well.

It is probably slightly overengineered to keep the ModulePreprocessor
interface in addition to PreprocessorPlugin (and similar for
postprocessors), but the split exists for historical reasons. And the
separation of concerns there is actually kind of nice as well, since it
makes it rather simpler to implement a ModulePreprocessor if you don't
care about the discoverability granted by making it a plugin. That said,
we don't follow this pattern for any other ImageJ plugin types, so it is
perhaps a bit strange here. But we'll leave it this way, for now.
ij-commands: rename imagej.core to imagej.plugins

This naming scheme is consistent with the commands being located in the
plugins/commands subfolder. The previous imagej.core prefix was
unsatisfactory because it misleadingly implied the code was part of
core ImageJ, when in fact it had nothing to do with ij-core.
ij-platforms: rename imagej.core to imagej.plugins

This naming scheme is consistent with the platforms being located in
the plugins/platforms subfolder. The previous imagej.core prefix was
unsatisfactory because it misleadingly implied the code was part of
core ImageJ, when in fact it had nothing to do with ij-core.
ij-scripting: rename imagej.core to imagej.plugins

This naming scheme is consistent with the scripting plugins being
located in the plugins/scripting subfolder. The previous imagej.core
prefix was unsatisfactory because it misleadingly implied the code was
part of core ImageJ, when in fact it had nothing to do with ij-core.
ij-text: rename imagej.core to imagej.plugins

This naming scheme is consistent with the text plugins being located
in the plugins/text subfolder. The previous imagej.core prefix was
unsatisfactory because it misleadingly implied the code was part of
core ImageJ, when in fact it had nothing to do with ij-core.
ij-tools: rename imagej.core to imagej.plugins

This naming scheme is consistent with the tools being located in
the plugins/tools subfolder. The previous imagej.core prefix was
unsatisfactory because it misleadingly implied the code was part
of core ImageJ, when in fact it had nothing to do with ij-core.
ij-uis: rename imagej.ui to imagej.plugins.uis

This naming scheme is consistent with the UIs being located in the
plugins/uis subfolder. The previous imagej.ui prefix was
unsatisfactory because it misleadingly implied the code was part
of the core ij-ui component, when in fact it was not.
WIP