In `MediaButtonReceiver`, don't always bail out for `KeyEvent != play`

Use case description

I recently switched an app from a custom playback service to the more "standardized" media3 MediaLibraryService. A problem I ran into is that a simulated media pause button event (sent as a broadcast) does not work anymore. This seems to be a deliberate decision; the MediaButtonReceiver bails out for key events that are not "play":

https://github.com/androidx/media/blob/aceb0bc9da047b1ddc29ed493af7a0751aeb8acb/libraries/session/src/main/java/androidx/media3/session/MediaButtonReceiver.java#L162-L165

Proposed solution

Is there a way for MediaButtonReceiver to detect whether the service it wants to start is already running? If it is already running, we do not risk a ForegroundServiceDidNotStartInTimeException by sending the key event to it. So it should be safe to relay all the other key events (pause, fast forward, etc) as well.

Alternatives considered

• Writing our own MediaButtonReceiver to do exactly that would of course be possible. However, I feel like adding this to the main media3 library as some kind of backwards compatibility layer could benefit additional users of the library and avoid them spending as much time on this as I have. Also, it avoids adding a bunch of custom code around media3 that needs to stay in sync with the original media3 implementation.
• Contact all third party app developers who control media playback and ask them to implement control via media sessions. I'm not convinced that I can convince several third party developers to do that. This is also not something we can tell to our users: "your macro button no longer works because we made a change forcing the developer of your macro button app to update their app". (even though our app update is in beta, we already got reports about two different 3rd party media control apps no longer working)