Changes

Fix Bug 606 - New AWT threading implementation breaks .. ; Fix GLAutoDrawable multi-threading w/ proper pattern (hope so)

Considering code changes and remarks:
  3ed491213f8f7f05d7b9866b50d764370d8ff5f6
  1a91ec5c8b6fd9d9db7bc115569c369fe7b38e9b
  3334a924309a9361a448d69bc707d4cce416b430
  4f27bcecf7484dc041551f52a5c49e2884cb3867

It seems necessary to have

- recursive locking employed for all semantic actions which changes drawable & context (and the Window resource)

- to avoid deadlock, we have to ensure the locked code segment will not spawn
  off to another thread, or a thread holds the lock, spawns of an action requiring the lock. .. sure

- other read-only methods (flags, ..) shall at least utilize a safe local copy of a volatile field
  if further use to produce the result is necessary.

- flags like sendReshape require to be volatile to guarantee it's being processed

Patch impacts: AWT/SWT GLCanvas, GLAutoDrawableBase [and it's specializations]
and hopefully closes any loopholes of missing a cache hit, etc.

If you review this and find optimizations, i.e. removing a lock due to semantics etc,
don't hold back and discuss it, please.

Align TestSWTAccessor02GLn w/ TestSWTJOGLGLCanvas01GLn, dropping the canvas cstr on SWT thread,
which seems not to be required.

Adding TODO note: Optimize/Fix NIO caching of glMapBuffer/glUnmapBuffer