SF: Fix display mode transitions for multi-display

SF does not yet support concurrent modeset on multiple displays, as the
scheduler/modeset/VSYNC state machines are tied to the internal display
that is powered on, a.k.a. the active display.

When SF detects a change in the DM policy for a display, it initiates a
transition to the new display mode, which includes syncing to its VSYNC.
However, the per-display calls to setDesiredDisplayModeSpecs that start
this process occur after the setPowerMode calls to turn off/on the old/
new active display, respectively. Before this CL, a change in policy on
the now inactive (powered-off) display triggered a partial display mode
transition (that would start resync but abort before HWC modeset), such
that SF wound up internally inconsistent and out of sync with HWC.

Fix this by deferring the applyRefreshRateConfigsPolicy of the inactive
display until it becomes active. Later, in onActiveDisplayChangedLocked,
the Scheduler::Policy is cleared by Scheduler::setRefreshRateConfigs, so
ensure that Scheduler::getPreferredDisplayMode subsequently initializes
Scheduler::Policy::mode to the chosen mode for the newly active display.
Otherwise, applyRefreshRateConfigsPolicy falls back to its default mode.

Bug: 260092798
Test: No intermittent jank on outer/inner displays after fold/unfold.
Test: DisplayModeSwitchingTest.multiDisplay
Change-Id: Iebe1a6bb4749630333ef954955ac33807c95dd9f
Merged-In: Iebe1a6bb4749630333ef954955ac33807c95dd9f