GestureConverter: fix inconsistencies from clicks during gestures

When button changes occurred during an ongoing fake-finger gesture
(scrolling, pinching, or swiping), the converter was producing an
inconsistent event stream, with DOWN events when pointers were already
down, UP events when they were already up, and similarly for
BUTTON_PRESS and BUTTON_RELEASE.

To fix this, make pressed buttons and in-progress fake-finger gestures
mutually exclusive from the perspective of a consumer of input events.
If a button press occurs while a gesture is in progress, it is dropped.
If a gesture starts while one or more buttons are down, we release them
before starting the gesture. (In both cases, the corresponding button
release events are also dropped, whenever they occur.) Gestures are
given priority over button states because this issue is most likely to
occur when the user is making a multi-finger swipe, presses down a bit
too hard, and presses the touchpad's button by mistake. For the same
reason, we don't send BUTTON_PRESS events for buttons that are still
down after a gesture, as this will likely result in unintended clicks.

Another approach I considered was to send BUTTON_PRESS and _RELEASE
events when the button state changes, and then be smart about when we
send DOWN and UP so that the stream is always in a DOWN state when
either a button is pressed or there's a fake finger from a gesture
present. This would give a more accurate representation of the actual
input, but could result in some pretty unusual event sequences. For
example, if a button is pressed during a three-finger swipe but doesn't
lift until after the swipe ends, you'd have a period after the two
POINTER_UPs at the end of the swipe but before the final UP (when the
button lifts), during which you might even have MOVEs, and the
classification would have to change at the last POINTER_UP, which isn't
done anywhere else. So the number of event sequences that consumers have
to support (or at least not behave badly when they receive) goes way up.
This would also be more complex to implement.

Bug: 372571823
Test: manually play around with various gestures while pressing and
      releasing the button, and check that the pointer doesn't lock up
Test: replay the recording from b/372571823#comment3, and check the
      pointer doesn't lock up:
      $ adb shell uinput - < recording.evemu
Test: patch change I59b886bfb632f0f26ee58c40f82f447f5ea59b41, then
      repeat the above steps with the input verifier enabled and check
      there are no crashes:
      $ adb shell 'stop && setprop log.tag.InputDispatcherVerifyEvents \
                   DEBUG && start'
Test: $ atest --host \
        frameworks/native/services/inputflinger/tests/GestureConverter_test.cpp
Test: $ atest --test-filter='GestureAndButtonInterleavings*' \
              --host inputflinger_tests
      (both of these test commands must be run due to b/391854943)
Flag: EXEMPT bug fix
Change-Id: I2c6f8f268fe804f187d972ab2170ea9b45374c64