Add service to track anonymous usage statistics
Add an interface for objects with URL locations

The initial use case is for ModuleInfo. Similar to Identifiable, it is
nice to able to ask a command or script: "In which URL are you defined?"
This is a different question than the delegate class, which is
Java-specific.
Make common module types implement Locatable
Record location of tracked objects, too

We will need this later, because we really want to verify, when
compiling usage statistics, which update site (if any) the relevant file
came from. If we cannot deduce the update site, we don't care about the
object's usage, because it is not part of the "known ecosystem" of
modules etc.
DefaultModuleService: include exception in log

When logging the error creating a module, include the exception too.

We have it, so we should pass it on. (If the stack trace is annoying
on the console, the answer is not to eat the exception, but rather
to change on information from the log is emitted to the console.)
Context: improve javadoc for explicit service list

When instantiating a Context with an explicit list of services,
compatible services will be loaded in the order given, regardless of
their relative priorities. For example, if you write:

    new Context(UsageService.class, EventService.class)

Then the DefaultUsageService will be loaded before the
DefaultEventService, resulting in the DefaultUsageService's event
handlers not being registered properly, since at the time of its
initialization the context's EventService will still be null.

So for the EventService in particular, it should almost always be the
first service given in the explicit list.

Presumably, there are similar problems when doing things like:

    new Context(SCIFIOService.class, SciJavaService.class)

Since the EventService matches SciJavaService but not SCIFIOService,
although I did not test this. We will either need to:

A) Change such constructions to list the core SciJava services first; or

B) Change the behavior of context creation such that all compatible
   services are _always_ loaded in priority order, regardless of the
   order of the specified service template types.

Otherwise, any services which register event handlers, but do not
depend on the EventService explicitly or transitively, will not work
as expected in such scenarios.
ClassUtils: add methods to get annotated methods

These methods are analogous to the getAnnotatedFields methods,
but for annotated methods rather than fields.
ClassUtils: skip Object when scanning for fields

The java.lang.Object class does not have any annotated fields at all.
And even if it did, it definitely does not have any fields annotated
with SciJava annotations such as org.scijava.plugin.Parameter, which
are the main sorts of fields we are interested in.
DefaultEventService: use getAnnotatedMethods

The ClassUtils class now contains a getAnnotatedMethods method, which
obtains all methods annotated with the given annotation class.
ClassUtils: add a TODO reminder

We may not _always_ need to include interfaces when
recursively scanning for annotated methods...
ServiceHelper: load EventService more aggressively

Whenever we have @EventHandler annotated methods, we need an
EventService to be loaded as a dependency. Otherwise, even if the
EventService is loaded later, those event handlers will not be properly
registered with it, since at the time registration was attempted, the
EventService was not yet loaded and hence null.

This change obviates the need for DefaultEventService being set to an
absurdly high priority, as explained at:

https://github.com/imagej/imagej/commit/b9abe178b813fb68aa49fdd7515a5e6698436793
EventServiceTest: test support for @EventHandler

Specifically, we test that when one or more @EventHandler-annotated
methods are present in a service, that it gets interpreted as a
dependency on EventService, even if there is no @Parameter-annotated
EventService field.
Context: remove obsolete warnings from javadoc

Now, when there are @EventHandler annotated methods, the EventService is
treated as a dependency. So it is no longer necessary to explicitly list
EventService.class before other services when constructing a Context
with an explicit list of service interfaces.
Add unit tests for UsageService behavior