NEWT WindowImpl.runOnEDTIfAvail(..): Run task from current thread if owning the windowLock. Avoiding deadlock when cmds issued from within locked code path.

This allows e.g. GLEventListener::display(..) { .. glWindow.setSize(100, 100); .. }
NativeSurface Cleanup (API Change) - Adapt to GlueGen Lock cleanup commit: 834b9e530e652b7ff7c5e222720bce3ad2b11c5f

- adapt to GlueGen Lock cleanup
- remove isSurfaceLocked(), use 'null != getSurfaceLockOwner()' instead

Misc:

- remove unused priv./impl. methods
- add @Override
Misc cleanup: add @Override
Misc cleanup: Add @Override, remove trailing whitespace
Misc cleanup: Add @Override, remove trailing whitespace
Capabilities cleanup: make most get*() final, impl. Comparable to CapabilitiesImmutable, Misc ..

- Comparable<CapabilitiesImmutable> to CapabilitiesImmutable:
  "interface CapabilitiesImmutable extends VisualIDHolder, WriteCloneable" ->
  "interface CapabilitiesImmutable extends VisualIDHolder, WriteCloneable, Comparable<CapabilitiesImmutable>"

- CapabilitiesImmutable and GLCapabilitiesImmutable get-methods final (most)

- GLCapabilitiesImmutable.compareTo: add doubleBuffered (between stereo and samples)

Misc:
  - Add @Override
  - remove trailing whitespace,
GLDrawable* cleanup: Add @Override, remove trailing whitespace, ..
GLContext* TRACE_SWITCH: Add GLContext instance hash value to allow tracking.
SWT GLCanvas: Fix destroy(), Remove local concurrency hack & out-of-process locking ; Revise threading code; Proper name for SWT unit tests.

SWT GLCanvas:
  - Fix destroy()
    drawable.setRealized(false); is being called within dispose() method

  - Remove local concurrency hack
    [MT-0] The hack: 'final GLContext ctx = getContext(); a = null != ctx ? ctx.something() : 0;'
    is thread safe locally, however, w/o covering the hole use case of the caller
    it makes no sense to add thread safe code here - would be only an illusion.
    In case any of the methods are called outside of a locked state
    extra care should be added. Maybe we shall expose locking facilities to the user.
    However, since the user shall stick to the GLEventListener model while utilizing
    GLAutoDrawable implementations, she is safe due to the implicit locked state.

  - Removing out-of-process locking
    [MT-1] Claiming the recursive lock in the dispose/display/.. methods
    and _then_ issuing a complex off-thread GL task could lead to deadlock.
    The GL task could involve calling GLEventListener methods, which itself
    could try to manipulate the GLCanvas -> deadlock.
    Similar to [MT-0] we may need to either find a proper locking mechanism
    or simply ignore it and reduce functionality.
    TBH .. the number of scenarious of the mentioned deadlock are very limited
    and exotic.

  - Revise threading code
    [MT-2] Besides the other MT-* remarks, the logic whether to spawn off
    the GL task and determination which thread to use is too complex and redundant.
    (See isRenderThread(), runInGLThread() and runInDesignatedGLThread())

  - Proper name for SWT unit tests.
    Reflect the semantics.
SWT/AWT GLCanvas multithreading annotations (see commit 1a91ec5c8b6fd9d9db7bc115569c369fe7b38e9b) ; AWT GLCanvas remove dead code.
NEWT GLWindow multithreading fix and annotations (see commit bc7503c77892a9e14b10e8b8e9ce48b148c6fa4c).

NEWT GLWindow multithreading fix:
  - Add required locking of display(), otherwise a drawable/context destruction of another threads
    could lead to [still] use asynced data.
AWT/SWT GLCanvas: Remove volatile of context instance, use drawable instance's volatile 'feature'
Bug #589 - Enhance snapshot/textIO test: Add offscreen mode; Add AWT onscreen/offscreen-layer resize test.