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 _almost_ did it that way. But I was concerned about the additional complexity: what if the `ServicesLoadedEvent` gets published before the `snaeService.wait(500);` call? But I guess that case is actually fine. And in my tests, it doesn't happen anyway given the overhead of queuing something up on the EDT: the wait happens before the notify every time, at least on my system. So sorry for being lazy about it.
3e5d8227a03e687583f0ac91da489cb7e37237f3