Constrain window position to monitor workarea

[Mr-Tao]

Summary

• Derive an effective window position from the selected monitor workarea.
• On non-centered axes, keep x_pos and y_pos as the user's requested
  position rather than overwriting them with a temporary constrained value.
• Use the same effective geometry for resizing, showing, and animation.
• Reapply both configured dimensions when the workarea changes, so a
  transiently larger workarea does not leave the window oversized.
• Add GLib tests for valid, edge-constrained, exact-size, oversized, and
  negative-origin geometries.

Problem

Tilda currently stores the configured position separately from the size that
it derives from the monitor workarea. This can leave those values inconsistent.

For example, with a 32-pixel top panel and a 3840x2160 screen, the workarea is
3840x2128+0+32. A non-centered Tilda configured at y_pos=37 fits at 99%
height. At 100%, xfwm4 keeps a size-only request fully visible and moves the
window to y=32. Tilda does not retain that effective position, so the next
hide/show moves the full-height window back to the configured y=37.

The workarea update handler also only grows an existing allocation. If the
workarea temporarily expands to the full 2160 pixels and then returns to
2128, the window retains the larger height and extends below the screen.

Approach

On non-centered axes, the configured coordinates remain unchanged and therefore
continue to express the requested position. Centered axes retain their existing
behavior of storing the recalculated centered coordinate. Tilda computes a
transient effective rectangle against one selected monitor workarea, constrains
it, and uses that rectangle everywhere that needs the displayed endpoint. This
means that returning from 100% to 99% height also restores the requested
y=37.

On every _NET_WORKAREA update, both dimensions are derived again from the
configured percentages. This makes workarea changes converge in both
directions instead of retaining an already larger allocation.

Validation

• Frozen-commit out-of-tree build with --enable-maintainer-flags.
• make check: all seven geometry cases pass.
• The patch applies cleanly to tag tilda-2.0.0.
• Xvfb + xfwm4 integration canary with a 32-pixel _NET_WM_STRUT_PARTIAL:
  • 100%, before toggle: 2300,32,1535,2128
  • 100%, after D-Bus toggle: 2300,32,1535,2128
  • 99%: 2300,37,1535,2106
  • animated toggle: 2300,32,1535,2128
  • y_pos remains 37 after clean process exit in every case.
• Xvfb + xfwm4 workarea cycle using the packaged binary:
  • initial 3840x2128+0+32: 2300,32,1535,2128
  • expanded 3840x2160+0+0: 2300,0,1535,2160
  • restored 3840x2128+0+32: 2300,32,1535,2128
  • y_pos remains 37.
• Live Xfce/xfwm4 check of the position path with a manual F1 hide/show
  cycle: 2300,32,1535,2128; all user configuration files remained
  byte-identical to their pre-install backup.

Behavioral note

When a requested rectangle does not fit inside the selected workarea, its
displayed position is constrained while it is shown. On non-centered axes, the
requested coordinates are not rewritten, so temporary panel, workarea, or
monitor changes do not cause configuration drift.