Use Priority.NORMAL_PRIORITY as the default
Improve how JHotDraw overlay adaption happens

There is now a JHotDrawService that manages the adapters, rather than
using a static utility class (JHotDrawAdapterFinder).

The adapters are now flagged using @Plugin rather than the custom
@JHotDrawOverlayAdapter annotation. The type of plugin is a sub-type of
Tool, with additional logic to adapt back and forth from a linked
JHotDraw Figure object.
Eliminate deprecated use of ImageJ.get method
Use double rather than int to store priorities

This is a better match for the common Prioritized interface and Priority
utility class.
Use very low priority for default JHotDraw adapter
DefaultAdapter: tweak style
Rename IJHotDrawOverlayAdapter to JHotDrawAdapter

This is a simpler name that is easier to read, and still conveys the
purpose for the most part. It is unlikely (famous last words!) that we
will have a *different* kind of adapter for some other entity within
JHotDraw, so hopefully dropping the "Overlay" from the name will be OK.

We also drop the "I" prefix because we are trying not to use the "I"
interface convention whenever possible.
JHotDraw adapters: rename *Adapter to Swing*Tool

This name is more in line with convention for Swing-specific
implementations of interfaces, and also hopefully more intuitive for
people looking for Tool implementations. (For example, if you are
looking for the rectangle tool, and search for *RectangleTool, you will
now find it, whereas before you would have needed to do a lookup on Tool
for all implementing classes and then browse through them.)

The "Swing" prefix is unfortunate, but it differentiates the
Swing-specific tool implementations from any other UI's implementation
(e.g., a possible future implementation of RectangleTool in pure AWT)
without needing to rely on the fully qualified package names.
Rename DefaultAdapter to DefaultJHotDrawAdapter

This name is more consistent with all of ImageJ's other DefaultFooBar
implementations of FooBar interfaces.
Add javadoc for JHotDrawTool implementations
Don't worry about serial UID warnings

We don't worry about them elsewhere in the ImageJ codebase, and our
Eclipse configuration is set to ignore them.

At some point we may reevaluate that policy (probably when someone wants
to start serializing something), but for now it is simpler.
JHotDraw tools: ignore unused Display parameter
Remove synthetic-access warning suppression

Our Eclipse configuration ignores these situations anyway; see:

    http://stackoverflow.com/questions/7046492/

The idea that leaning on a synthetic accessor method could result in a
performance hit on modern JVMs is very silly.
AbstractUploader: add javadoc
Make Progressable an abstract class

This is necessary to sort out the forthcoming interface hierarchy
associated with AbstractUploader: the addProgress(Progress) and:
removeProgress(Progress) methods need to be defined in an interface, so
next we will extract out Progressable as the interface for
AbstractProgressable, and use the interface elsewhere in the codebase.
Extract Progressable interface from implementation

This will enable us to also extract an Uploader interface from
AbstractUploader, to facilitate the transition from @Uploader to
@Plugin(type = Uploader.class).
Extract IUploader interface from implementation

This will facilitate the transition from @Uploader to @Plugin(type =
Uploader.class).
Add comment to empty method body

This fixes an Eclipse warning.
Add getProtocol method to uploader interface

This is in preparation for the removal of the @Uploader interface in
favor of @Plugin(type = Uploader.class).
Improve how upload mechanisms are managed

There is now an UploaderService that manages the mechanisms, rather than
using static utility methods (e.g., FilesUploader#getUploader(String)).

The mechanisms are now flagged using @Plugin rather than the custom
@Uploader annotation. The Uploader annotation's protocol attribute has
been pushed to the IUpdater#getProtocol() API method.