Simplify the media button handling logic

Here's the new media handling logic.

1. If the foreground app consumes the media key event
  (Activity.onKeyDown/Up() or Activity.setMediaController()),
  we stop here.
2. Find the media app whose AudioPlaybackConfiguration becomes
  PLAYER_STATE_STARTED lastly across the boot. The media app is the app
  with the media session.
  - If its session is still alive, send the media key event
    to the media session.
  - If its session has been released but the session set the media
    button receiver, send the media key event through the media button
    receiver.
  - If it has multiple media sessions, pick the media session whose
    PlaybackState matches with the AudioPlaybackConfiguration's player
    state.
3. Stop here. Don't try revive any other app.

This approach has two limitations.
1. If an app has multiple AudioPlaybackConfigurations and/or
   media sessions, the MediaSessionService may pick the wrong media
   session to send media key events.
2. If an app with a media session plays sound effects differently from
   the SoundPool class, the MediaSessionService would consider the app
   as the lastly played media app.

Bug: 33032080
Test: Manual tests as follows
  1. Checked that the lastly played app receives the media key events
     although the app's media session doesn't report its playback state.
  2. Checked that the lastly played app receives the media key events
     although the app's media session is released.
  3. Checked that the lastly played app doesn't receive the media key
     events if its playback is remote.
Change-Id: I1fd6f9eee0750da4dea9fcc7401fdb1c3f249a72