The GVariant we are getting here might not be coming
from GTK+, but rather from some other source. Best to
be forgiving and deal with missing data without crashing.

This was causing the GTK+ portal backends to crash on
print requests from Qt.

Before now, down/up keys on H Ranges would increase/decrease value resp,
which is unintuitive & worse, contradicts what we already do for scrolls

Fix simply by moving to the new should_invert_move() as scrolls just did
– which also gets us the other benefits explained in the last 2 commits.

https://bugzilla.gnome.org/show_bug.cgi?id=407242
https://bugzilla.gnome.org/show_bug.cgi?id=791802

This fixes RTL and/or :inverted Ranges responding to a horizontal scroll
by moving the value/slider button in the opposite direction... See prev.

https://bugzilla.gnome.org/show_bug.cgi?id=791802

This will be used in subsequent commits to fix the sign by which the
value is changed in response to directional scroll or keypress events.

The idea is: you have a movement to make – in the form of a delta that
follows widget directions, i.e. −1 means left or up, +1 means right or
down – and you want to know whether that delta needs to be inverted in
order to produce the intuitively expected directional change of :value.

The existing should_invert() is not sufficient: it just determines
whether to invert visually, but we need more nuance than that for input.

To answer that – while not doubling up the work for scrolls and keys – I
add a helper should_invert_move(), which considers other relevant state:

 • A parallel movement on priv->orientation should just use the existing
   should_invert(), which already worked OK for this case (not others).

 • Movements on the other orientation now depend on priv->orientation:

    ◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
      widget coords) always means increase value & vice-versa. This was
      done in get_wheel_delta(), but move it here for use with keys too.

    ◦ For a vertical Range, ignore :invert as it’s only relevant to the
      parallel orientation. Do not care about text direction here either
      as RTL locales do not invert number lines, Cartesian plots, etc.

This returns TRUE if the delta should be inverted before applying to the
value, and we can now use this function in both scroll and key handlers.

https://bugzilla.gnome.org/show_bug.cgi?id=407242
https://bugzilla.gnome.org/show_bug.cgi?id=791802

If widgets want to clip things, they now need to do it themselves.

By not taking care of clip, we avoid the need to track clip. And by not
tracking clip, we can avoid all unnecessary cache invalidations that we
were doing for render nodes whenever the clip changed.

And when you are scrolling, the clip changes *a lot*.

priv->button is a guint, but we assigned it to a local gint.

gtk/gtkmenushell.c:734:37: warning: comparison between signed and
  unsigned integer expressions [-Wsign-compare]
           if (button && (new_button != button) && priv->parent_menu_shell)
                                     ^

These are members of the private struct, so it hurts no one to fix this.

Everything that calls this already ensured we are a valid GtkMenu.