Fix App Handle visibility and input heuristics

This is a second attempt at fixing b/371473978. The first attempt
(I015d6cc0e9a857ed16d749e552a1eabe181f66b5) tried a couple of things:
1) Use TO_BACK transit changes to signal to window decoration that a
task was becoming invisible. This was necessary because fullscreen
apps entering or exiting split-select did not result in its window
decoration getting an onTaskInfoChanged() callback with
|isVisible=false| which was the normal path to hiding the Handle or
disabling the input layer. However, this introduces a new problem:
ALL recent transitions result in the task going TO_BACK, even if it is
still visible, so swipe-to-home, quickswitch, etc started hiding Handles
(and Headers). This was fine for handles in that CL because (as seen
below) it was acceptable UX to hide them, but it also hid Headers
unintentionally.
- This change reverts that part of the CL, and instead fixes the
  underlying issue with missing onTaskInfoChanged() updates: that
  changing the windowing-mode of the task to MULTI_WINDOW in the
  request-split WCT causes ShellTaskOrganizer to not find any listener
  for this task in onTaskInfoChanged() - because it is not yet a
  root/stage child, nor is there a generic multi-window task listener
  registered.

2) Handle visibility and input layer visibility were decoupled, but the
calculation for both remained the same (isCaptionVisible()). This was
partly because the CL originally intended to hide the Handle on
recents transitions, but did is not the desired UX (for neither Handles
or Headers).
- Decoupling is still useful because we do want to hide the input layer
  on recents transitions because the Handle should not be touchable even
  if visible. So this CL keeps the two decoupled, but adds a
  showInputLayer() that ensures it is hidden during if recents is
  running.

Flag: com.android.window.flags.enable_input_layer_transition_fix
Bug: 403683274
Test: open fullscreen app - test that during swipe-up, quickswitch and
overview the App Handle (and headers) remain visible, but the input
layer is not responsive.
Test: open fullscreen app, swipe to home and quickly drag from where the
handle was - verify the drag-to-desktop gesture isn't invoked (which
previously brought back the closed app to the front)
Test: open fullscreen app, enter split select - verify the input layer
is not responsive, exit split select - verify that remains the case if
going home, or the handle visiblity/input returns to normal if going
back or entering split (repeat for freeform -> split-select)
Test: no regressions in split-select animations

Change-Id: I911dee347f1f2541418a64358ad188114aa9e023