ij-data: fix alphabetization of dependencies
DatasetService: add I/O convenience methods

These methods allow you to open, save and revert datasets.

They are extremely similar to similar methods currently provided by
IOService, as well as the SaveAsImage command in ij-commands. The reason
to centralize them here is in preparation for a generalization of
IOService act as a HandlerServer for arbitrary IOPlugins. After that
happens, DatasetService will be the compile-safe place to open and save
datasets, whereas IOService will be the general-purpose place to open
and save data of any type.
Use new DatasetService I/O methods

In preparation for removal of the Dataset-specific I/O methods from
IOService, we switch over to using the shiny new DatasetService I/O
methods designated for this purpose.

Most of the changes are very straightforward and have resulted in much
simpler code. Note that the changes to SaveAsImage are a bit involved
though; although its complexity was reduced in some places, a few hacks
remain until SCIFIO's ImgSaver becomes better at N-dimensional saving.
Add an I/O plugin type for extensible data I/O

This plugin will go hand in hand with the new, forthcoming IOService,
providing a generalized and extensible mechanism for opening and saving
data (e.g., the File > Open and File > Save commands).
Remove the obsolete StatusDispatcher class

It was only used before SCIFIO converted to the SciJava Common
application container and started using the built-in StatusService.
Add an I/O plugin for Datasets

It is short and sweet thanks to the new DatasetService I/O methods.
Add an I/O plugin for text formats

It standardizes incoming text to HTML, so that it can ultimately be
displayed in an HTML-based rich text viewer.

The implementation is nice and simple thanks to the TextService.
Add an I/O plugin for LUTs

The implementation is simple because it leans on the LUTService.
Refactor the IOService and move it into ij-core

The IOService has kept the same package (imagej.io) but migrated into
ij-core, because its dependency on ij-data has been purged. It is now a
general-purpose service fitting the Handler pattern (see
HandlerService), with available IOPlugins extending its capabilities.

The FileEvent hierarchy has been repurposed as IOEvent:

* image.io.event.FileEvent -> imagej.io.event.IOEvent
* image.io.event.FileOpenedEvent -> imagej.io.event.DataOpenedEvent
* image.io.event.FileSavedEvent -> imagej.io.event.DataSavedEvent

These events are now published whenever the IOService opens or saves
data, so individual IOPlugins do not need to care about it.

The ImageFileDragAndDropHandler has been generalized into a
FileDragAndDropHandler which uses the IOService to handle *any* File
which is dropped into ImageJ.

Lastly, the RecentFileService and OpenFile command have been updated to
reflect these API changes.
DatasetIOPlugin: make low priority

The problem seems to be that SCIFIO is too aggressive about what it
thinks it can handle; e.g., when trying to open a .txt file, the
DatasetIOPlugin gets selected.

To avoid this, we simply move DatasetIOPlugin to the bottom of the list.
Although this is a hack which ultimately we should not need, determining
whether an arbitrary file is in *any* supported image format is going to
be an expensive operation no matter what, so for performance reasons it
makes sense to leave the priority of this I/O plugin lower anyway.
LUTService: add a FIXME note about display of LUTs

As things stand, we do not have a proper Display implementation for
LUTs. Simplest would be to enhance the ImageDisplay to support
ColorTables in addition to just Data objects. Then ColorTables would
work as output parameters; e.g., OpenFile could open and display them.
Add I/O plugin stub for scripts

It doesn't work yet, because the ScriptService does not yet provide the
API necessary to actually open the script in the script editor.
Merge branch 'io-plugins'

This branch modularizes ImageJ's I/O framework, and truly completes
ticket #9.

All image I/O is handled by SCIFIO via the DatasetIOPlugin, which leans
on the DatasetService to do the work. But other types of I/O -- scripts,
LUTs, results tables, whatever -- each get their own extension for the
Open and Save commands in the File menu to work as expected.
Add horrible hack to avoid a javac bug

It's the same old problem with ImgOpener using a <T> parameter that
cannot possibly be inferred from the calling code. The openImg method
returns an ImgPlus<T> but does not pass in any parameters that use T.
And javac *really* hates that...
DefaultLUTService: fix method order

Public methods come before private ones; see:
http://developer.imagej.net/coding-style#Ordering_of_code_blocks
LUTFileDragAndDropHandler: create new LUT display

At the moment, passing a ColorTable to the DisplayService's
createDisplay method does not work, but that will be remedied shortly.
So in anticipation of that, let's change the LUTFileDragAndDropHandler
to make use of it directly.

This eliminates the use of the LUTService's special-case createDisplay
method, in favor of the DisplayService's general-purpose method.
LUTService: change createDisplay to createDataset

The only functionality we really need here is the ability to wrap a
ColorTable in a Dataset that displays it as a ramp. We can then lean on
the DisplayService to wrap that Dataset in a display if needed.
DefaultImageDisplay: add support for ColorTables

The default image display can now display a ColorTable by wrapping it in
a Dataset using the LUTService#createDataset method.

This change also improves the code organization in the createDisplay
method to eliminate duplicate code blocks.
Merge branch 'lut-display'

This branch makes the Open command display LUTs properly,
fixing ticket #1406.

It works by enhancing ImageDisplay to support ColorTable
objects by wrapping them as Datasets.