LutService: improve the API

It is now possible to inquire whether a given file is a LUT, to load
LUTs from InputStreams, to create a new display showing the given LUT
argument as a ramp, and to apply a LUT to given existing image display.
Improve drag-and-drop API and modularize handlers

First of all, each DragAndDropHandler now has a generic parameter
indicating its native supported Java object type. It provides methods
for checking compatibility with objects of that type, with
DragAndDropData objects, and with arbitrary Objects. To avoid confusion,
these methods now all have different signatures.

DragAndDropHandlers now support queries by Class<?> rather than only
MIME type, since it is usually much more convenient to implement a
handler for a specific Java class than for a specific MIME type.
(Although of course supporting a specific MIME type is still possible.)

There is now an AbstractDragAndDropHandler layer that implements the
lion's share of the DragAndDropHandler methods with default
implementations. Most concrete subclasses now require only a minimal
amount of effort and code to implement.

Previously, there was a lot of functionality embedded in individual
drag-and-drop handlers, as well as a lot of case logic. Embedded
functionality has migrated to service calls, and case logic has now been
split out to separate handlers or eliminated where possible.

Generally speaking, the scope of each individual handler should be very
focused, and should not contain any "business logic" regarding how to
actually deal with the dropped objects, but rather should merely hand
them off to a relevant service as appropriate.