patch 9.2.0010: Using Wayland compositor is still slow

patch 9.2.0010: Using Wayland compositor is still slow

Problem:  Using the Wayland backend in GTK, rendering remains slow due
          to per-line redraws, unnecessary Cairo push/pop groups, and
          scroll operations that allocate new surfaces repeatedly.
Solution: Improve rendering performance (Christoffer Aasted).

This commit does the following:
- Add gui.is_wayland to detect Wayland backend
- Avoid blocking the input loop
- Skip early redraws; let the compositor handle full-screen redraws
- Use CAIRO_OPERATOR_SOURCE to overwrite instead of blend
- Reuse scroll source region for destination scroll region
- Optimize fast scroll-up
- Remove cairo_push_group/pop_group and cairo_clip in scroll path
  to reduce allocations (~50MB saved on 4K fractional scale)

Since Wayland redraws the entire screen between updates (unlike X11),
further performance gains are possible by batching drawing in other code
paths, e.g.:
- message.c: batch lines to avoid scroll
- term.c: batch terminal redraws

These could be refactored later to deferred redraw with Wayland.

closes: #19062

Signed-off-by: Christoffer Aasted <dezzadk@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>