Changes

Animator*: Clarify debug output

GLContext*/GLDrawableHelper: Fix consistency of recursive makeCurrent()/release()/destroy() calls ; Enable context switch tracing ; GLCanvas: proper AbstractGraphicsDevice destruction

GLContext*/GLDrawableHelper: Fix consistency of recursive makeCurrent()/release()/destroy() calls
  Utilizing volatile and lock.tryLock(0) for lockConsiderFailFast(),
  reducing redundant synchronization and using RecursiveLock implicit sync.

  GLContext 'early-out' is the case where the thread already holds the
  context, ie. context is already current and the native makeCurrent is skipped.

  makeCurrent()'s 'early-out' w/o incr. the recursive lock of GLContext
  and it's NativeSurface could lead to asymetry in lock/unlock count
  with release()/destroy() calls. The 1st release actually released the
  native ctx already.
  Properly utilize recursive lock/unlock in all cases and impl. 'early-out' after locking.

  Following the above in GLDrawableHelper.invokeGL()'s 'early-out' case as well,
  ie calling makeCurrent()/release() symmetrical.

  Introduce GLDrawableHelper.disposeGL(), which issues dispose on all GLEventListeners
  within a current context and issued context destruction directly.
  This simplifies GLAutodrawable's destroy/dispose calls and ensures
  that the above sequence of events happens atomically (lock is being hold until destruction).

Enable context switch tracing
  If property 'jogl.debug.GLContext.TraceSwitch' is defined, trace context switch.

GLCanvas: proper AbstractGraphicsDevice destruction

GLContext/NativeSurface Impl's toString(): Add lock.toString()

TestAWTCardLayoutAnimatorStartStopBug532: Refine, add 'continue' mode, ..

Previous commit 098398c2a9145447da5314eed9792b3738c2d515 cleaned up
and fixed context/drawable lock/unlock for makeCurrent()/release()/destroy()
and consistency is looks much better now in this regard.

However, on Intel HD 3000 / Windows7, our AnimatorControl start/stop still
let the 2nd switch to GLCanvas within the CardPanel not showing rendering results.

One interesting artefact though:

1st switch 2 GLCanvas (rendering visible):
*** hdc 0x2f010ec5, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
*** hdc 0x160110c4, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
*** hdc 0x2f010ec5, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
*** hdc 0x160110c4, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
-> alternating HDC's

2nd switch 2 GLCanvas (rendering _not_ visible):
*** hdc 0x160110c4, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
*** hdc 0x160110c4, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
*** hdc 0x160110c4, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
*** hdc 0x160110c4, hdw(hdc) 0x1003a0, hdw 0x1003a0 - AWT-EventQueue-0, com.jogamp.opengl.util.Animator[started true, animating true, paused false, drawable 1]
-> fixed HDC

Maybe this is a hint for what is going wrong in JAWTWindow locking,
which aquires the frame's HDC.

Verifying the recursive lock shows proper lock/unlock actions though.