ServiceHelper: simplify getService method calls
ServiceHelper: use correct generic parameter

All we know about the Class in question, at this juncture, is that it
*extends* Service, not that it *is* Service. So we should use
"Class<? extends Service>" rather than just "Class<Service>".

Of course, due to runtime erasure of generics, it does not actually
matter that much, but it's nice to get things right...
Bump development version to 2.0.0-SNAPSHOT

Commits further down the line will make changes which break behavior in
the following ways:

1) The Context constructor will throw IllegalArgumentException in cases
   where required service dependencies are not found. Previously, the
   framework would warn loudly (emitting a stack trace) in case of
   missing required services, but would always try to finish creating
   the context.

   Note that services can be marked as optional by implementing the
   Optional marker interface, and service dependencies can be marked as
   optional by adding "required = false" to the relevant @Parameter
   annotation. If this is done, the context creation will continue
   without throwing IllegalArgumentException.

2) As long as we are bumping to a major version anyway: the EventUtils
   class is obsolete and will be removed, in favor of the
   Context#inject(Object) method, which subscribes to events *and*
   also fills in service dependencies marked with @Parameter.

Fortunately, all in all, these changes are quite minor, so in most cases
it should still be possible to upgrade the version of SciJava Common
used to the 2.0.0 without any compile-time or runtime breakage.
ServiceHelper: change how service deps are filled

The context construction is now more aggressive about failing when
required services are not able to be filled.

A service can be marked optional by implementing the Optional interface,
in which case the context's service population will continue even if
that service cannot be filled.

For transitive service dependencies, if the dependency is marked with
"@Parameter(required = false)" then it is considered an optional
dependency which also will not halt service population with an
exception, but rather merely be set to null.

Otherwise, if a required service cannot be filled,
IllegalArgumentException is thrown. In the case of a transitive
dependency failure, the IllegalArgumentException will have a chain of
causes that clearly identify the ultimate culprit, as well as the
dependency chain which triggered the failure.

In all cases, invalid services are still logged as warnings, with a
stack trace when in debug mode.
Add tests for Context creation with services

We check that contexts get created (or not) in various situations,
with service dependencies of various natures.
Inject context and service parameters

This change allows services (and contexts, too) to be declared as
instance fields annotated with @Parameter.

They can then be automatically populated by calling
Context#inject(Object). In the case of objects which extend
AbstractContextual, it also works to call
Contextual#setContext(Context).

This capability will allow a great reduction in the number of calls to
Context#getService(Class). Right now, both ImageJ2 and SCIFIO call
getService all over the place, but it makes eminently more sense to use
this new injection mechanism, which guarantees the presence of required
services at injection time, rather than potentially seeing
NullPointerExceptions later when getService(...).doSomething() is
actually used.
Add tests for @Parameter injection mechanism

We want to make sure that *any* class which has @Parameters of type
org.scijava.service.Service or org.scijava.Context has those parameters
populated with the context's associated values, when
Context#inject(Object) is called on it. We also want to make sure that
*if* the object implements the Contextual interface, the result is
exactly the same when calling Contextual#setContext(Context).
Optional: tweak javadoc
Context: always subscribe to events when injecting

Previously, AbstractContextual#setContext(Context) would subscribe to
events for the object (i.e., those annotated with @EventHandler), but
calling Context#inject(Object) would not do so.

This commit changes the behavior to be the same across the board.
ContextInjectionTest: add event subscription tests

We now subscribe to events whenever AbstractContextual#setContext or
Context#inject is called, so let's test that it works properly.
EventUtils: remove this obsolete class

It is now easy to subscribe to events using Context#inject(Object) or
Contextual#setContext(Context). Unsubscription is no longer needed,
either.
PluginInfo: remove deprecated method
Log: remove this deprecated class

The LogService provides a flexible and contextual way to log messages.
Merge branch 'service-parameters'

This branch vastly enhances the Context#inject(Object) method. In
addition to calling Contextual#setContext(Context) for objects which
implement that interface, it also A) scans for fields annotated with
@Parameter and populates them with available services; and B) registers
any methods annotated with @EventHandler with the EventService.

The practical consequence is that it should be necessary *much* less
often to call Context#getService(Class) to obtain desired services.
Rather, you can simply declear your needed service dependencies as
instance fields, annotate them with @Parameter, then call
Context#inject(this) to populate them via reflection.

One potential downside to this approach is performance, since reflection
*is* being used, but there are many advantages:

1) reduced boilerplate code;

2) improved code safety, with missing services and circular
   dependencies much more obvious at injection time;

3) improved code readability, with a class's dependencies being much
   more obvious, including whether each dependency is required or not.

This branch also alters how context creation works: specifically, an
IllegalArgumentException can now be thrown in the case of missing
required services. See 10e895440cd789c7696a75d842fa38f2be4dfc25 and
1fe242c47758bb32177cda7fc2a15950f3fa5592 for further details.

Lastly, this branch bumps the development version to 2.0.0-SNAPSHOT due
to these breaking changes, and removes a few deprecated classes and
methods, since we are dealing with a major version bump anyway.