GTK4 issues found by SWT test suite #3743

A while ago @akurtakov asked me to test GTK4, which I finally found the time for.
Here are the GTK4 bugs our internal SWT test harness found.
Each one is a difference from SWT on GTK3, which behaves like Win32 and Cocoa here.
Tested on master (3376e19), GTK 4.22.4 against GTK 3.24.52, X11 backend (GDK_BACKEND=x11).
If a description is not sufficient, let me know.

Input and events

• Display.post synthesizes nothing and returns false for every event type, so SWT tests cannot post mouse or key input on GTK4.
• Clicks on Button, List, Table and Tree send no MouseDown/MouseUp; List sends a MouseUp without the MouseDown before it. Listeners that react to mouse down/up (drag start, context actions) never run.
• Text and Combo send Modify without a preceding Verify when typing, so VerifyListeners that filter or reject input (numeric fields, length limits) have no effect.
• A double click sends MouseDoubleClick before the second MouseDown; GTK3, Win32 and Cocoa send MouseDown (with count 2) first and then MouseDoubleClick, so code that handles the press in MouseDown sees the double click first.
• Shifted letters and symbols report the shifted character as keyCode (72 'H' for Shift+h, 33 '!' for Shift+1), while GTK3, Win32 and Cocoa report the unshifted key (104 'h', 49 '1'). Key bindings that check keyCode together with SWT.SHIFT stop matching.
• FocusIn is also sent to the ancestor composites of the control that receives focus, so focus-tracking code (for example part activation) sees extra focus events. Seen for Text, List, Table, Tree and Spinner, by click, Tab traversal and forceFocus().
• Check Button toggled with Space: Selection arrives between KeyDown and KeyUp, instead of after the key is released as on GTK3.
• Spinner sends no Verify when its value changes through the arrow buttons, the Up/Down keys or the mouse wheel; GTK3 sends one before the Modify.
• Spinner sends Modify before Selection (arrow buttons and Up/Down keys), the reverse of GTK3.
• Slider: a thumb drag ends without the final Selection with detail = SWT.NONE, the mouse wheel fires no MouseWheel event and moves by a different step than on GTK3, and the slider takes keyboard focus, which it does not on GTK3.

Table and Tree

• Dragging a column header fires no TableColumn/TreeColumn Resize or Move, and dragging a movable column does not reorder the columns, so user column resizing and reordering are invisible to the application.
• With a visible header, item geometry and hit testing use two different origins: TableItem.getBounds(int) includes the header height (item 0 at y = 28) while TableItem.getBounds(), getTextBounds and all TreeItem bounds start below it (y = 0), and getClientArea() (y = 28), getItem(Point) and toDisplay count from the widget top, so getItem at a point inside item.getBounds() returns null or the previous row. GTK3 uses one origin for all of them. getItemHeight() also reports 25 while the rows are 23 px apart.
• Control.setOrientation(SWT.RIGHT_TO_LEFT) on a Table or Tree that has columns throws UnsatisfiedLinkError, because it calls GTK3.gtk_container_forall, which does not exist in GTK4.

Graphics

• GC.drawFocus paints nothing (0 pixels for drawFocus(10, 10, 40, 12) on an Image; GTK3 paints a ring), because it renders with the style context of the shell, which has no focus outline on GTK4.

Display

• The device zoom ignores GDK_SCALE and stays at 100 with GDK_SCALE=2, so the UI renders at 100% (Display._getDeviceZoom; the GTK4 branch of getPrimaryMonitor always takes monitor 0).