Bump to newest parent to get ij1-patcher >= 0.10.0

We need it for the new interceptCloseAllWindows and disposing hooks.

This is accomplished by bumping the parent pom-imagej to version 2.34,
which declares ij1-patcher at the required version.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
DefaultLegacyHooks: make closeAllWindows do more

When ij.WindowManager#closeAllWindows() is called, there are some
windows that it fails to close down. In particular, any non-Frame
non-image windows such as PlugInDialogs are not handled. For example,
the ContrastAdjuster spawns a new thread which will only terminate
when the ContrastAdjuster window is disposed, but the
WindowManager#closeAllWindows() method will not do that.

Further, ImageJ1 does not grant the user the opportunity to confirm
dismissal of certain types of windows. Specifically: under certain
circumstances, any non-image window which is not an
ij.plugin.frame.PlugInFrame, ij.plugin.frame.Editor or
ij.text.TextWindow will be forcibly dismissed via its dispose() method.

See:
https://github.com/imagej/ImageJA/blob/v1.49c/src/main/java/ij/WindowManager.java#L391-L401

As such, and keeping in mind that ImageJ1 is intended to run as an
end user application in its own dedicated JVM, this commit makes the
closeAllWindows routine go the whole nine yards, and really close down
_all_ Windows in the JVM, while _always_ giving the user the opportunity
to cancel closing them down. Of course, it would be ideal to close down
only those windows associated with ImageJ1, but unfortunately we have no
way of knowing for certain which windows those are, since an ImageJ1
plugin can create and show any arbitrary Windows of its choosing,
without registering them with the WindowManager.
When shutting down IJ1, dispose the context too

There are essentially two ways ImageJ1 can be shut down:

1) From the ImageJ1 side; i.e.: ij.ImageJ#quit()
2) From the SciJava side; e.g.: LegacyService#dispose()

When IJ1 is shut down via its quit() routine, it should be done
"softly", asking the user to confirm the closure of various windows,
etc., before finally disposing of ImageJ1's resources as well as the SJC
context. System.exit should be called under exactly the same
circumstances as when IJ1 would normally do it.

When IJ1 is shut down via the legacy service, it should be done "hard",
without prompting the user to confirm anything. This form of shutdown
should not trigger a disposal of the SJC context, since A) it might
already be in the process of being disposed; and B) if it isn't already,
then it is almost certainly not desired for it to happen.

This change makes sure that when IJ1 is shutting down in the former
case, the SJC context gets disposed too, but that when IJ1 is shutting
down in the latter case, an SJC disposal is _not_ triggered.
DefaultLegacyHooks: add a convenience constructor
Add regression tests for shutdown behavior

The tests check three scenarios:

* ij.ImageJ#quit() with exitWhenQuitting set to false
* LegacyService#dispose()
* LegacyUI#dispose()

A separate integration test will be needed to test ij.ImageJ#quit() with
exitWhenQuitting set to true, since surefire and failsafe cannot support
tests that result in System.exit being called.
Add integration test to verify shutdown behavior

This test needs to use maven-invoker-plugin to run in a separate JVM,
because ImageJ1 calls System.exit(0) upon successful shutdown. We really
want to verify that indeed this action occurs.

Note that maven-surefire-plugin and maven-failsafe-plugin do not support
System.exit getting called from tests, so using maven-invoker-plugin is
the best way to go here.
ShutdownTest: make the tests work in Eclipse

This fix is necessary to avoid problems with the EclipseHelper.
Otherwise, the context class loader from one test -- which has been
modified by ImageJ 1.x and the legacy layer -- bleeds into the next
test, causing it to fail.

Thanks to Johannes Schindelin for suggesting the solution.
Make imagej-ui-swing non-optional

The original thinking (which we unfortunately did not write down
anywhere that we could find) was probably that depending on
imagej-legacy should not require the project to inherit the
imagej-ui-swing dependency, since it is a UI-specific component.

However, the relevant legacy code using the net.imagej.ui.swing
classes (in particular, the TextEditor of the Script Editor) was not
careful to catch all ClassNotFoundExceptions etc. in cases where the
imagej-ui-swing was not also present on the classpath.

Further, the imagej-legacy project's purpose is to manage the
interaction with ImageJ1, which is inherently an AWT & Swing based
application. So there is no advantage to restricting dependence on
Swing-based libraries anyway.

Better is to simply declare it as a normal dependency. Then if someone
wants to exclude the dependency, they can do so... at their own risk.

This change eliminates the nasty exception stack traces from the output
of the ij1-quit integration test.