Changes

Bug 1421: Demo wrong NEWT Child window position within an SWT TabFolder layout using NewtCanvasSWT on MacOSX with High-DPI Retina

Bug 1421: NewtCanvasSWT child on layouted SWT parent only occurs on MacOS, regardless of High-DPI

Bug 1421, Bug 1358, Bug 969, Bug 672: Generalization of test case TestGLCanvasSWTNewtCanvasSWTPosInTabs (1/2)

Testing the TabFolder and a SashForm in the 2nd tab
covering both SWT layout use cases on both out SWT support classes SWT GLCanvas and NewtCanvasSWT.

Merging  TestBug1421NewtCanvasSWTPosInTabs + TestBug672NewtCanvasSWTSashFormComposite
into TestGLCanvasSWTNewtCanvasSWTPosInTabs.

TestBug672NewtCanvasSWTSashFormComposite exposes that SWT GLCanvas
still requires work for proper High-DPI scaling on OSX!

Bug 1421, Bug 1358, Bug 969, Bug 672: SWTAccessor: Add get[Location|Size]InPixels(..) and getLocationOnScreen()

Bug 1358: GLCanvas: Call new OSXUtil.SetWindowPixelScale(..) when GLCanvas gets realized on MacOS

This fixes GLCanvas's High-DPI scaled size issue on MacOS of Bug 1358.

SWT GLCanvas: Fix NPE in DEBUG mode; NewtCanvasSWT: Resurect comment in setBounds(..)

Bug 1421, Bug 1358, Bug 969, Bug 672: Generalization of test case TestGLCanvasSWTNewtCanvasSWTPosInTabs (2/2)

Complete merging unit tests.

Bug 1421, Bug 1358, Bug 969, Bug 672: Deleting merged tests (obsolete)

Bump SWT to Release 4.14-201912100610 (jogl/make/lib/swt)

Due to issues on MacOS, added the src.zip for MacOS as well.

Bug 1421: OSXUtil: Add GetLocation(..), simply returning the view's frame position

Bug 1421: Move Bug 1362 'setBackground(..)' fix before potential 'setNEWTChild(..)'

Bug 1421: Minor cleanup / commenting

Bug 1421: Minor commenting

Bug 1421: Tackle wrong position of TabFolder, SashForm etc

getClientArea() on MacOS produces a 'difficult' result regarding the position,
which usually is returned as zero.
Using a zero position issues the bug w/ SashForm, where the offset doesn't seems
to be covered by the native NSView nor an SWT parent Composition.

Then using the getLocation() as is (i.e. the view's frame position)
may also cause issues with the TabFolder, as it includes the tab's trimming.
Here the native NSView 's position includes the tab's trimming,
gladly the parent (TabFolder or a Composition)'s clientArea includes this offset.

Therefor, as a testbed - on OSX, getClientArea2(..) returns
- position: getLocation() - getParent().getClientArea().position
- size: getSize()

This at least works OK'sh using
- no special layout parent
- TabFolder
- SashForm

++++

Unit test TestGLCanvasSWTNewtCanvasSWTPosInTabs: Adding 'addComposite' to test matrix.
'addComposite' wraps our GLCanvas or NewtCanvasSWT into a Composite instead of
adding it directly into the layouting parent.

It demonstrates an issue with the new test 'test32_NewtCanvasSWTTabSashGLWComp',
i.e. the NewtCanvasSWT is shown on the left as the SashForm's offset is being dropped.

Summary:
- No more issues with High-DPI pixelScale observed!

- GLCanvas is being most well layouted, no issues in tests

- NewtCanvasSWT may show severe positioning issues -> test32_NewtCanvasSWTTabSashGLWComp
- NewtCanvasSWT always shows a small positioning offset into the lower-right corner w/ overlapping
- NewtCanvasSWT overall positioning is not perfectly understood
- NewtCanvasSWT misses to hide the NEWT child when changing tabs in TabFolder

Bug 1358: Merely simplifying the non MacOS getClientAreaInPixels() code path

This also demonstrates that on non MacOS, SWT's scale-factor is artificially imposed
on the actual pixel-units, as SWT's getClientArea() is simply returning:
  DPIUtil.autoScaleDown(getClientAreaInPixels())