Usage statistics service

This branch adds a service for tracking usage statistics. The service can currently track any object that implements the `Identifiable` and `Locatable` interfaces (the latter being new to this branch). It would be possible to generalize things even further, but I think this approach is good enough for our initial use case: tracking module executions. In that regard: the service subscribes to `ModuleExecutedEvent` and tracks usage of the executed modules via their `ModuleInfo` descriptors, which typically implement the two necessary interfaces, at least in the case of `CommandInfo` and `ScriptInfo`.

This branch also fixes a serious bug discovered incidentally: services with `@EventHandler` methods but which do not explicitly depend on the `EventService` may not have their event handlers subscribed properly when creating a `Context` with an explicit list of service interfaces. We avoided this problem in the past for full-blown contexts (created using the noargs constructor) by [setting the priority of the `DefaultEventService` absurdly high](https://github.com/imagej/imagej/commit/b9abe178b813fb68aa49fdd7515a5e6698436793),  but that was really an incomplete solution that papered over the actual issue. This branch finally fixes things properly by inferring an `EventService` dependency whenever one or more `@EventHandler` methods are present. I was slighly worried about the performance of more recursive class scanning to make this possible, but the performance difference is negligible in my tests (276 vs. 286 ms average creation time for a full-blown context with complete classpath), so I think it is OK.

Both the new `EventService` dependency logic and the `UsageService` are unit tested down the middle.

See also the `usage-statistics` branch of some other repositories, which are not yet ready to merge:
* [imagej-usage](https://github.com/imagej/imagej-usage/compare/usage-statistics)
* [imagej-updater](https://github.com/imagej/imagej-updater/compare/usage-statistics)

I am reluctant to promise thread safety for the service. I'd rather add a comment to the service saying that it is _not_ thread safe, and up to calling code to be careful about that.

I know it's a cop-out. But I see many downsides to ensuring thread safety:
* Performance issues with synchronized code
* Need to unit test that thread safety is delivered, which is a pain
* Complicates the code, making it harder to understand
* All for essentially no benefit when it comes to our own use cases for the service

This is a case where I am actually OK with a little technical debt, because I think the future potential price of running into multithreaded issues with this service, and then fixing them, would be outweighed by the immediate time cost of doing all the synchronized stuff and writing the unit tests.