Add new MIME type helper class

I was reluctant to do it, but the MIME types are complex enough (with
the parameter list of key/value pairs) that it seems necessary.

AWT already has a MIME type helper class,
java.awt.datatransfer.MimeType, but: A) it is part of AWT, which is not
available in all Java environments, particularly Android; and B) it is
not a public class anyway.

Pivot also has a MIME type helper class, org.apache.pivot.util.MIMEType,
but we do not want to add a Pivot dependency directly to ij-ui.

So unfortunately we reinvent the wheel again here.
Update drag-and-drop package to use MIMEType class
DefaultDragAndDropData: inject context in ctor

Currently, nothing is using the DefaultDragAndDropData implementation.
But if something were to use it, because it is Contextual, we need to
ensure the Context is provided.
Make drag-and-drop handlers compatible with nulls

AWT uses Transferable objects that internally have a list of
DataFlavors. Each DataFlavor has a MIME type and associated Java class.
You can ask a Transferable to give back its data in any supported
DataFlavor. Unfortunately, if you do this too early in the process (such
as during the DropTargetListener#dragEnter event of a drag-and-drop
action), an InvalidDnDOperationException is thrown because AWT does not
consider the system to be in an appropriate state to extract the data.

As a consequence, the drag-and-drop handlers cannot obtain the data
currently being dragged (e.g., not even the filenames of dragged files).
Hence, the isCompatible(DragAndDropData) methods cannot inspect the
dragged data in any more detail than the MIME type and Java class.

To work around this, the AWTDragAndDropData class's getData(MIMEType)
implementation now catches InvalidDnDOperationException and returns
null, and the UI-agnostic ImageJ drag-and-drop handlers have been
changed to trivially accept null data. The handlers' drop
implementations also trivially return true, although in practice at that
point (DropTargetListener#drop event) they should be able to obtain the
actual non-null data via the Transferable.
MIMEType: improve compatibility test

We now require testing against another MIMEType rather than just a MIME
type string. A "compatible" MIME type is one that has the same base
string, as well as all the same parameter names and values as the one
being tested against, although the given MIME type is allowed to also
have additional parameters as well.

This change also improves the equality test: two MIME types are equal if
they are compatible in both directions, meaning they really do have
*all* the same parameter names and values. The equals method is not
performance optimized, but as written is hopefully easy to understand.
(And nothing in the framework currently needs to call equals anyway.)

This change fixes the behavior of AWT drag-and-drop data to detect
compatible MIME types properly now.
DragAndDropService: show only if drag is supported

This is how Barry had done it before, but I thought I'd be clever and
display more information about the drag-and-drop handler chosen.
However, in practice, it's pretty much always the ListDragAndDropHandler
(at the top level at least). So the message is pretty useless, and it's
not friendly to the user to show a fully qualified Java class name.

So we revert to the simple "Drag and Drop" message instead, for now...