AppUtils: add getMainClass method

This enables querying of the class whose main method launched the
application. It is not perfect, but seems to work in practice.
AppUtils: be smarter about null baseSubdirectory

The getBaseDirectory(File, String) method allows specification of a
baseSubdirectory hint indicating the expected subdirectory structure
beneath which the class should be found. However, in some cases, we
cannot know what to expect, and so pass null for this hint.

Previously, a null hint was equivalent to the empty string; that is,
getBaseDirectory would return the containing directory directly, rather
than any ancestor directory. Unfortunately, that is not really the
correct behavior when querying any ImageJ class, since they all belong
to some submodule or other of the multi-module Maven project structure.

Hence, this change adds a heuristic that scans upward for Maven POMs.
Once a directory is found without a POM, it is assumed that the previous
directory is the toplevel one with respect to the ImageJ project
structure. This enables certain invocations to be more effective; e.g.:

  AppUtils.getBaseDirectory(AppUtils.getMainClass())

Previously, the above code would erroneously return some subfolder of
the ImageJ project structure. But since we pass a null hint,
getBaseDirectory now takes the liberty of searching for the true
base directory rather than a subdirectory thereof, using the heuristic
described above.

Of course, the heuristic will fail if a developer places a pom.xml file
in the parent directory of the ImageJ working copy. (And it can in fact
be useful to do that, to create a synthetic multi-module build that
includes ImageJ along with other projects.) But for most use cases the
heuristic is sufficient. If anyone complains, one potential solution
would be to actually parse the pom.xml files looking for values that
match the toplevel ImageJ POM.
AppUtils: generalize getBaseDirectory() logic

The getBaseDirectory() method now delegates to:

  getBaseDirectory(getMainClass())

in cases where searching from imagej.util.AppUtils fails.

This will happen, e.g., when running using "mvn exec:exec" from the
command line, since the imagej.util.AppUtils class will be contained in
a JAR file deep within ~/.m2/repository.

This change allows the base directory to be detected in more cases,
since it no longer assumes the main class is imagej.Main from ij-app.
Updater: fix ImageJ base directory detection

This change partially reverts commit
226a9f56cf9f1eb7dd41e6b73ea3898470a9d089.

With the preceding improvements to AppUtils.getBaseDirectory(), the
no-args signature is now robust enough to be called in this situation.

The rationale is that explicitly asking for the base directory with
respect to imagej.updater.util.Util.class will fail in the case where
that class is contained in a JAR file in the Maven local repository
cache. This is in fact the case when launching ImageJ via Maven
("mvn exec:exec" from the app subdirectory). Unfortunately, if the
Updater's Util class fails to detect the ImageJ base directory, its
static initializer throws an NPE, which means the class does not load.
This wreaks all sorts of havoc, and ImageJ fails to start up properly.
Updater: fix minor style issues and warnings