[roll] Roll fuchsia [audio] ADR device errors and callbacks

Clarify the circumstances in which the client-provided
callback or the ControlNotify notifications will be invoked,
and when it will not. Generally, if the device encounters a
fatal error we notify the client immediately and start the
process of removing the device from the list of available
devices. Thus, if during a client call we see that the
device is already in the error state, we can simply exit and
allow the unwind-upon-error process to proceed. Any pending
FIDL calls will be completed as cancelled when the Control
or Observer connections are closed, which occurs as a
result of the device being removed.

Methods that would previously emit an extraneous callback
or notification, upon discovering that the device is already
in the error state, have been updated to not do so. These
include Device methods that implement device support for:
  Control/SetDaiFormat
  Control/CodecStart
  Control/CodecStop
  Control/Reset
  RingBuffer/CreateRingBuffer
  RingBuffer/Start
  RingBufferStop
  RingBuffer/SetActiveChannels
In these cases (as well as others where we already correctly
exited without callback/notification), a new comment makes
it clear why we do this.

Also, the sequence of checks at the beginning of every
client-callable method is clarified and made consistent.
For methods that require a Control, this is checked first.
Then DeviceType is checked, then whether the device has an
error. Following these, other validation occurs, such as the
presence/validity of required parameters (e.g. element_id).
This should help guarantee that these checks always occur.

Original-Bug:   b/352602005

Test: audio_services_device_registry_unittests
Test: audio_services_device_registry_warning_unittests

Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1087881
Original-Revision: d977f7228f369846ebe3f2b11a48a122dc2e079b
GitOrigin-RevId: 939618110215644a2fae5cd90b1a3fc81a7b8766
Change-Id: I9b6135050b9a243b85a5d7f1914b55c46deae07a