AudioService: refactor audio mode stack

Refactor stack used for audio mode management
and update logic to determine audio mode owner to better
accomodate concurrency and misbehaving VoIP apps:
- A non privileged app is considered active if it plays or records for
VOICE_COMMUNICATION.
- Do not remove inactive VoIP apps from the stack but flag them as
inactive. An inactive, non privileged app cannot be selected as mode
owner for mode IN_COMMUNICATION.
- The most recent privileged app if any or active non privileged app is
selected as audio mode owner when current audio mode is evaluated.
- Audio mode evaluation and setting to native server always happens in
the message handler.
- Update active state in playback and recording monitor callbacks
instead of by polling.
- When an app enters the stack or becomes inactive, give it a grace period
in active state after which the active state is evaluated again. This
avoids spurious brief mode changes on playback/record transitions.
- Add dumpsys entries for audio mode stack

Bug: 174714082
Test: atest AudioManagerTest
Test: Manual audio smoke tests

Change-Id: Id4d12c855ca1ac79beccb34e751aeae593acf6d7