[GTK] Remove forceResize() from getClientArea on Wayland and the org.eclipse.swt.resizeOnGetClientArea property #3717

On GTK, Scrollable, Composite, Table and Tree call forceResize() in getClientAreaInPixels() only when RESIZE_ON_GETCLIENTAREA is set:

static final boolean RESIZE_ON_GETCLIENTAREA = OS.isWayland() || Boolean.getBoolean("org.eclipse.swt.resizeOnGetClientArea");

Bug 484682 removed the call in 2020 because a getter changing widget state led to a stack overflow.
The -Dorg.eclipse.swt.resizeOnGetClientArea=true property was added as an escape hatch to the old behavior, and nothing in the Eclipse projects sets it.
Shortly after, the call was restored for Wayland only (ff04b13, "temporary workaround"), because the PDE API Baseline edit dialog and the JDT Pull Down wizard rendered wrongly on GTK 3.24.14 under Wayland.
The follow-up, Bug 563191, was never worked on.

A check on GTK 3.24.52 under a headless Wayland compositor found no remaining need for it.
JFace wizard dialogs modeled on the two reported ones (a checkbox tree page, a checkbox table sizing its columns from getClientArea()) and a ScrolledComposite sized from getClientArea() produced identical bounds, client areas and column widths for all 106 controls with and without the forced resize.
Instrumenting the call sites showed that none of the 186 forceResize() calls made through getClientArea() changed the allocation that is returned afterwards.

Proposal: remove RESIZE_ON_GETCLIENTAREA, the four forceResize() calls it guards, and with it the org.eclipse.swt.resizeOnGetClientArea system property, so that Wayland and X11 behave the same.
Before merging, the real PDE API Baseline edit dialog and the JDT Pull Down wizard should be opened once on Wayland with the change.