SF: Flow DisplayModeRequest through mode set FSM

The motivation is to:
    - Avoid redundant state that can cause data races if stale.
    - Consolidate control flow for resolution and refresh rate changes.
    - Clarify the desired/pending/active states of the per-display FSM.

The notable changes are:

Consume the desired DisplayModeRequestOpt via either SF::dropModeRequest
or DisplayDevice::initiateModeChange.

Pull the details of SF::finalizeDisplayModeChange into DisplayDevice::
finalizeModeChange, which now returns whether there was NoModeChange,
a ResolutionChange, or a RefreshRateChange. Consume the pending request.

Now that DisplayDevice does not retain the desired DisplayModeRequest,
applyActiveMode as soon as finalizeDisplayModeChange ends, rather than
at a later point in the commit, when initiateDisplayModeChanges checks
whether the active and desired modes are the same.

Now that applyActiveMode happens in finalizeDisplayModeChange, remove
the special case when there is a displayToUpdateImmediately.

Bug: 305813445
Bug: 255635711
Bug: 241285876
Test: ALOGV of mode setting for inner/outer displays
Test: InitiateModeChangeTest, DisplayModeSwitchingTest
Change-Id: I688b0c922747a80e881965a1dc243d11ba2c7438