On macOS, when AWT enters a nested event loop and it wants to have only related messages
processed by that secondary loop it specifies that the current NSRunLoop should enter a
special named mode. It also includes this name in the list of modes used when scheduling
a selector to run so that it matches the current run loop.

This means that any code that wants to run on the AppKit thread whilst this mode is in effect also needs to specify this mode.

Since the intention is to block code not specifying that mode, this could be seen as reasonable.

The present problem is that the deprecated JNF library would add this run loop mode to any call made
using its utility APIs to run on the main thread. So if any code used this whilst Java is in this nested
mode it would still run.

The run loop mode is just an NSString but there needs to be either a supportable, documented,
shared (at runtime) way of finding out what it is, *or* JDK needs to stop specifing that special mode.

Documenting it isn't particularly desirable since it also implies a lot about the JDK implementation
which goes beyond what we would ordinarily do, more so than other JAWT type interfaces.
On the other hand dispensing with the mode is obviously not risk free and there may be some
technical obstacle to it and will require substantial bake time

So this bug will be used to investigate these alternatives, and perhaps other, and choose.