_getNativeWindowingType() TYPE_BCM_VC_IV autodetection.

Signed-off-by: Xerxes Rånby <xerxes@zafena.se>
".bcm.vc.iv" is enough now -> NEWT agnostic relative package path.
Add braces and fix indentation to conform with jogl coding standards.
Merge pull request #52 from xranby/bcm.vc.iv-autodetect

_getNativeWindowingType() TYPE_BCM_VC_IV autodetection.
Workaround for Bug 623: Sporadic XCB assertion failures w/ ATI proprietary driver and w/o native X11 locking

The proprietary ATI X11 driver does not handle multi-threaded [GL] clients well,
i.e. triggers an XCB assertion 'from time to time'.

It almost seems like that the driver either:
  - aliases all display connections to it's connection name, i.e. server; or
  - utilizes a build-in display connection w/o locking, used for some reason

+++

- X11Lib: Add QueryExtension(dpy, name) allowing early driver determination w/o GL

- X11Util detects 'requiresGlobalToolkitLock' and 'markAllDisplaysUnclosable' via
  X11 extensions. In case certain ATI extensions are available, both are set to true.

- X11GLXDrawableFactory: Dropped setting 'markAllDisplaysUnclosable', using X11Util's detection (see above).

- New GlobalToolkitLock to satisfy certain driver restrictions (ATI's XCB multithreading bug)

- NativeWindowFactory handles new property requiresGlobalToolkitLock,
  in which case the new GlobalToolkitLock is being used instead of ResourceToolkitLock.

- JAWTUtil ToolkitLock locks GlobalToolkitLock 1st to match new 'requiresGlobalToolkitLock' property.

- Document static method requirement of X11Util, GDIUtil and OSXUtil via marker interface ToolkitProperties

- ToolkitLock: New method 'validateLocked()', allowing use to validate whether the device/toolkit
  is properly locked and hence to detect implementation bugs. See unit test class: ValidateLockListener
Bug 623: X11Util adds property 'nativewindow.debug.X11Util.ATI_HAS_NO_MULTITHREADING_BUG' to disable GlobalToolkitLock workaround for testing.
Merge remote-tracking branch 'origin/master'
X11Util: Detailed closing information only in DEBUG mode, just print summary
NullToolkitLock.validateLocker(): Throw exception if locking is required (detecting impl. bugs)
test script: remove deleted unit test
JAWTUtil ToolkitLock: Add lock counter to make lock validation recursive (Fix regression of commit 92398025abdabb2fdef0d78edd41e730991a6f94)
Relax Bug 613 workaround of commit 92398025abdabb2fdef0d78edd41e730991a6f94

Utilizing a GlobalToolkitLock in general to lock the display connection results in deadlock
situations where locked surfaces signal other [offscreen] surfaces to render.

We have to see whether we find a better solution, for now sporadic XCB assertion still happen.
But it is preferrable to point to the root cause, then to jumping through hoops to complicate locking
or even to deadlock.

Locking:
  - X11GLXGraphicsConfigurationFactory add missing device locking in:
    - getAvailableCapabilities
    - chooseGraphicsConfigurationStatic

  - Newt/X11Window: Discard display events after window close.

Relax ATI XCB/threading bug workaround:
  - ToolkitProperties: requiresGlobalToolkitLock() -> hasThreadingIssues()
  - NativeWindowFactory: Don't use GlobalToolkitLock in case of 'threadingIssues' the impact is too severe (see above)
  - NativeWindowFactory: Add getGlobalToolkitLockIfRequired(): To be used for small code blocks.
                         If having 'threadingIssues' a GlobalToolkitLock is returned, otherwise NullToolkitLock.
  - X11GLXContext: [create/destroy]ContextARBImpl: Use 'NativeWindowFactory.getGlobalToolkitLockIfRequired()' for extra locking

Misc Cleanup:
  - *DrawableFactory createMutableSurface: Also create new device if type is not suitable
  - *DrawableFactory createDummySurfaceImpl: Pass chosenCaps and use it (preserves orig. requested user caps)
Fix commit fbe331f013608eb31ff0d8675f4e4c9881c9c48b (Bug 616 - Remove XInitThreads())

X11Util/Native: Fix X11Util_initialize0() arguments were wrong and code still invoked XInitThreads() .. woops;
                Added missing included "jogamp_nativewindow_x11_X11Util.h" incl. it's generation via javah,
                which was the culprit of not detecting it at compile time.
                This is a fix for commit fbe331f013608eb31ff0d8675f4e4c9881c9c48b
FBObject/GLFBODrawable: Debug / glError detection

- Enh. Debug output a bit
- FBObject: Detect glError @ syncFramebuffer MSAA blit, throw GLException if glError to fail-fast

- TODO: May add Mesa NoFBOMSAA Quirk to disable even trying it ..
GLRendererQuirks.NoDoubleBufferedPBuffer: Set if ( mesa || gallium ) && hwAccel
Misc: Add commented-out NEWT X11/XCB-Event and X11ScreenRandR1[13] compilation ; ...

Adding [dead] native source files for NEWT/X11:
  - X11Event and XCBEvent
  - X11ScreenRandR11 X11ScreenRandR13

They are currently excluded from compilation, however I like do version them for later use.
NativeWindowFactory: Remove 'remedy' of Bug 613 Commit 92398025abdabb2fdef0d78edd41e730991a6f94 GlobalToolkitLock for create/destroy

Turns out on it has no effect and ATI prop. driver still has XCB failures at this point.
Misc: tests.sh
Fix regression of fbe331f013608eb31ff0d8675f4e4c9881c9c48b [Remove XInitThreads()]

NativeWindowFactory.getDefaultToolkitLock() is no more a global singleton,
but an instance which has to track/lock a single resource.
Hence the decoration w/ it in GLDrawableFactory is useless and applying lock/unlock
on a new instance also a bug/regression.
Update PMVMatrix/GLMatrixFunc API doc and refine PMVMatrix update / get-Mvi/Mvit-Matrix operation. (Minor API change)

Using bitmask for requested Mvi and Mvit matrices,
same as dirty-bits to ease matching and update operation.

Update of Mvi and Mvit will be performed only if it's dirty-bit and request-bit set within update().
The individual dirty bit is cleared only if it's matrix update is performed.

Update is also issued at get-Mvi/Mvit-Matrix operations
to ensure proper values w/o update call w/o clearing the modified-bits.

update() returns true if the Mvi or Mvit matrix got updated
_or_ one of the modified bits is set. update() clears the modified-bits.

Adding explicit getModifiedBits() to get and clear it's state.

Adding unit test.

Lots of API docs ..