Fix deadlock between APS and sound trigger middleware

SoundTriggerMiddlewareValidation.setCaptureState() acquired a lock,
which is also acquired by load{Phrase,}Model() and unloadModel(),
which in turn call into audio policy service for the sake of
acquiring/releasing sound trigger capture session handles.

Since audio policy manager is single threaded, a deadlock may result
if setCaptureState() occurs concurrently with one of the model loading
operations:

- System server thread is in the process of loading, acquired the lock
  in SoundTriggerMiddlewareValidation and calls into APS, blocked
  waiting to acquire the mutex of APM.
- Audio server thread is in the process of changing the capture state,
  acquired the APM mutex and is calling into sound trigger middleware,
  blocked waiting to acquire the lock in
  SoundTriggerMiddlewareValidation.

The fix is simple: no need to lock SoundTriggerMiddlewareValidation if
using an atomic for the capture state. Verified by careful reading of
the code that this is the only contention point.

Bug: 154383165
Test: Hard to verify a rare deadlock, ran a quick verification of
      basic sound trigger functionality.
Change-Id: I1350316521d56d7de74f20ad980f92f0df0035f8