Bug 1054: Cleanup GLContext 'lock' and 'drawable' usage, perform drawable null check in constructor.

This patch merely cleans up 'lock' and 'drawable' usage,
while fixing:
  - constructor: Add drawable null check -> IllegalArgumentException
  - setGLReadDrawable: Proper precondition checks
  - setGLDrawable: Proper precondition checks

Affected methods of mutable drawable for which we have to consider locking:
  - setGLReadDrawable
  - setGLDrawable
  - release
  - destroy
  - makeCurrent
Bug 1054: Cleanup GLContext: 'lock' -> 'contextLock'
Bug 1054:  GLContext: makeCurrent() needs a null-check of [mutable] drawable; Review null checks and synchronization/locking.

'drawable' field of GLContextImpl is mutable via setGLDrawable(..),
which requires high-level locking as documented.

The required high-level locking allows us to _not_ add special
synchronization to this field (and drawableRead).

A simple null-check in makeCurrent() shall be sufficient,
plus ensuring mentioned high-level locking is applied.

GLContextImpl 'drawable' and 'drawableRead' synchronization:
  - commit ad79bd072b600a3f2416cc6f0c61e2925000069d check of null drawable is sufficient
  - Add GLAutoDrawable upstream-lock locking to:
    - AWT GLCanvas setupPrint/releasePrint
    - AWT GLJPanel (was missing)

Misc:
  - validate shared-context native-surface locking, throw exception if not successful
  - pixelDataEvaluated does not need to be synchronized, since it's being called while context is current, locking
  - GLDrawableHelper.recreateGLDrawable(..): Remove redundant glFinish() call
Bug 1055 - Access and query shared master GLContext in a deterministic fashion ; Don't use arbitrary shared context as 'master'.

GLContext* passes the shared-master to GLContextShareSet,
which only creates a sets of shared contexts
without differentiating the master context.

GLContext*'s shared-slave attempts to lock
the realized shared-master's surface at creation.

Currently only an arbitrary shared context is selected
due to the missing 'master' identity.
The arbitrary shared context's surface is locked
and its shared context handle used to create the slave context.

Lacking of using the user given shared-master
can lead to deadlock situations - and locking a 'wrong' surface.

+++

The patch:

  - Allows query the user given shared-master!

  - Use the user given shared-master for locking and it's
    context handle for the slave's creation.

  - The shared-context mapping maps each shared-master
    to a shared-slave within one shared-context-set,
    allowing deterministic and individual shared-master queries.
Bug 1054: Revert dfb9ed47ac6d8e85f6ae5fe166e7a6e28ca8ff83: Cannot change protected field name w/o breaking backward compatibility
Refine test cases for synchronous GLAutoDrawable display, swap-buffer and read-pixels (non-MSAA and MSAA) Bugs: 841, 975 and 1020