Fix issue with incorrect drag starter being used and handle removed tasks

- This CL has two parts:
  1) We were always using the split starter to start tasks, but if the
     top-task when the drag started is removed, then it will incorrectly
     attempt to bring forward another task to split with, or if there
     are no other tasks, it will leave the device in a broken split
     state
  2) In order to handle 1), we need to update the drag session and
     layout when tasks are removed while a drag is active.  We do this
     by registering a listener on the organizer (it doesn't need to be
     synchronized with the removal, just notified), and then we
     recalculate the running task to determine whether dropping should
     launch in fullscreen or split

Flag: EXEMPT bugfix
Bug: 346694675
Test: atest WMShellUnitTests
Test: Start a drag, kill the app behind and ensure that the drag can
      still continue without ending up in a broken split state
Change-Id: I7009389102005e20563973b48143488e86628715

0 files changed, 0 insertions, 0 deletions