Migrate PTService hierarchy from ImageJ

This is the same code previously merged to imagej.git with
c15a02888b8e5065c8730381324c154a9f66e134, viewable online at:
https://github.com/imagej/imagej/commit/c15a02888b8e5065c8730381324c154a9f66e134

These classes are of general utility beyond ImageJ; e.g., SCIFIO and
even SciJava Common itself will be able to make use of them.

Here is a reposted narrative describing the work:

This code introduces additional layers into the service and plugin type
hierarchies. It was done because many services and plugins were starting
to express very similar patterns, and include copy-and-pasted
boilerplate code. The following layers are now available:

1) A PTService manages a particular type of plugin. It uses the
	 PluginService to discover available plugins of that type, and
	 provides accessor methods to access the list easily.
	 Examples: CommandService, OptionsService

2) A SingletonService is a PTService that creates and maintains a list
	 of SingletonPlugins -- one singleton instance per plugin discovered.
	 Examples: CalculatorService, ThresholdService, PlatformService,
	 ToolService

3) A TypedService is a PTService whose plugins are typed on a particular
	 generic parameter, which defines a type of data object relevant to
	 those plugins. Both TypedService and TypedPlugin implement the
	 Typed interface, which provides a supports method, so you can inquire
	 whether a particular data object is supported by a specific plugin,
	 as well as by the TypedService as a whole.
	 Examples: None (but see SingletonService and WrapperService below)

4) A WrapperService is a TypedService whose plugins wrap data objects of
	 their given type. These WrapperPlugins each know how to "wrap" (via
	 the WrapperPlugin#set method) a subset of data objects of their given
	 type. The WrapperService can thus provide a master create method
	 which takes a data object and returns a new instance of the most
	 appropriate plugin, determined by iterating over the available
	 WrapperPlugins in priority order.
	 Example: WidgetService

5) A HandlerService is both a SingletonService and TypedService, which
	 maintains a list of HandlerPlugins (which are typed singletons, of
	 course). These plugins each know how to "handle" a subset of data
	 objects of their given type. The HandlerService can thus handle data
	 objects of that type by iterating over the available HandlerPlugins
	 in priority order. The exact handling mechanism is unspecified,
	 however, and will depend on the specific type of HandlerPlugin.
	 Examples: TextService, DragAndDropService
Manage event handler registration explicitly

There is now a dedicated Service method, registerEventHandlers, that
subscribes the event handlers (by delegating upstream to
AbstractContextual). The reason is: as things stood, it was required to
always call super.initialize() in Service implementations to ensure that
event handlers were registered. This is too much of a burden on third
party programmers, resulting in boilerplate code that is easily
forgotten, and hence mysterious service failures.

Since the ServiceHelper takes care of calling Service#initialize(), it
may as well also call Service#registerEventHandlers() explicitly
afterwards, to ensure that the event handlers are *always* registered.

The end result is that downstream code generally no longer needs to call
super.initialize(), which is much simpler and less error prone.
Add important note to Service API methods

The two Service API methods, initialize() and registerEventHandlers(),
are not intended to be called by downstream code! Rather, the service
framework itself calls these methods to initialize the service.