feat(coreaudio): add macOS system audio permission helpers

[thewh1teagle]

I was using cpal 0.18.0 (master) for loopback recording on macOS and needed to check and request the System Audio Recording permission before recording. Without it, recording succeeds but
captures only silence.

Added three public functions on macOS:

• cpal::check_system_audio_permission() — silent check, no UI
• cpal::request_system_audio_permission() — shows system prompt, blocking
• cpal::open_system_audio_settings() — opens Privacy & Security > System Audio Recording

Uses the private TCC framework (kTCCServiceAudioCapture) via libloading. block2 and objc2-core-foundation were already transitive dependencies so no significant dep overhead.

Related

• Suppport ScreenCaptureKit loopback #876 (comment)

[SuperKenVery]

I think it might be better if we check permission when recording from an output device, and if we don't have it, request it.

Do you think it's better? cc @roderickvd

If you agree, I can file a PR agains your branch!

[thewh1teagle]

Feel free to create a PR against my branch or open another PR with me as a co-author :)

[roderickvd]

Thinking out loud:

Since requesting permissions is a blocking operation showing a system-modal dialog, how about taking a middle road? In LoopbackDevice::from_device() we only check_system_audio_permission() which is non-blocking. If we don't have permissions, we return a new error variant. This catches the silent-silence bug without any blocking UI side-effects.

Then, we keep request_system_audio_permission() and open_system_audio_settings() as public API, so that a user can explicitly decide to request a blocking modal.

Going forward I would like to expose host-specific functionality with extension traits. Please refer to #1074 for an ongoing discussion how to do that for ASIO (getting the API right for all hosts) as well as an outlook on how to expose new error variants.