… setup to prevent WebRTC deadlocks (#197)

## Description
This PR makes two small but important changes to improve thread safety
and reduce deadlock risk in the iOS bindings:

### 1. RTCAudioTrack.mm

- Remove the explicit [self removeAllRenderers].
- Instead, iterate _adapters and remove each sink from the native audio
track without switching threads, aligning the behavior with
RTCVideoTrack.mm.
- This simplifies teardown and avoids extra synchronization points.

### 2.RTCFrameCryptor.mm

- Remove factory.signalingThread->BlockingCall around
nativeRtpReceiver->SetDepacketizerToDecoderFrameTransformer(...).
- The native call path already runs on the worker thread, so performing
a BlockingCall from the signaling thread introduces an unnecessary
signaling → worker hop that can increase deadlock risk in tight
teardown/configuration sequences.

## Problem Solved

- Redundant signaling → worker thread switching during audio renderer
cleanup and frame-cryptor configuration could contribute to deadlocks
under timing-sensitive conditions (e.g., track teardown overlapping with
transformer setup).
- By eliminating that extra hop, we reduce contention between signaling
and worker threads without changing observable behavior.

## Impact

- Lower likelihood of hangs/deadlocks on teardown/configuration paths.
- Implementation now matches RTCVideoTrack.mm for audio cleanup.
- No public API changes.

---------

Co-authored-by: Hiroshi Horie <548776+hiroshihorie@users.noreply.github.com>