[flexiglass] Fixes destinationScene-related crash when swiping.

This crash has started to happen once SceneInteractor.previousScene was added to the
codebase and a couple of scene implementations started to use it in
order to build their destinationScenes flow. Those scenes were the
bouncer scene which needs to return to the previous scene and the QS scene which can go back to the lockscreen or gone scene if that's where the user navigated from (skipping the shade scene with a from-edge and/or two-finger swipe down).

Initially, the crash would only occur upon illegal transition, so we get
bugs like b/333939922 which required a series of actions to trigger the
crash. We then proceeded to add an assert that can catch the problem
earler, which is what ag/26982215 resulting in a much earlier crash (as
soon as any scene is changed); the resulting exception helped diagnose
and understand the bug here.

There are two layers to this bug, both of which are fixed in this CL:
1. A reliance on previousScene to produce the destinationScenes from a
   Scene implementation can produce incorrect situations where the
   previousScene is the same as the Scene that's using it. To address
   this, I fixed the current problems and to discourage this "foot gun"
   from hurting us again, I changed SceneInteractor.previousScene to be
   a function that accepts an optional scene to ignore. The idea is for
   Scene implementations to pass in their own key so that previousScene
   emits null instead of emitting the same SceneKey as that of the
   observing Scene. The reason this can happen is because Scene
   implementation can continue to hydrate their destinationScenes flows
   even before or after they are the current scene.
2. A lack of synchronization between the currentScene and the
   destinationScenes as seen by the SceneContainer composable. If these
   are out-of-sync for a frame, the builder lambda we pass into the
   SceneTransitionLayout will associated the destinationScenes map from
   the previous scene to the current scene, sometimes resulting in the
   same illegal state described above, where STL is told that a
   UserAction can lead from the current scene to itself. This was fixed
   by moving the destinationScenes flow into the view-model and making
   it subsurvient to the currentScene flow.

Test: manually, verified that all current scene transitions that are
created by user interaction do not crash. The only exception was the one
described in b/333939922 which I couldn't verify because hitting the QS
edit button didn't open the bouncer, presumably because of the ongoing
work on ActivityStarter? But I'm not sure.
Test: added unit tests for relevant class changes
Fix: 335718219
Flag: ACONFIG com.android.systemui.scene_container DEVELOPMENT

Change-Id: I0d920739f30b6d77460cac355b46c0949a2f7ee9