[Metal/hal] Add metal::Queue::add_wait_event / add_signal_event for synchronization with external APIs

[AdrianEddy]

Description

This PR adds add_wait_event and add_signal_event (with matching remove_* companions) to wgpu_hal::metal::Queue. They stage MTLCommandBuffer::encodeWaitForEvent / encodeSignalEvent calls on an MTLSharedEvent for the next Queue::submit(), enabling GPU-side coordination with externally imported resources sharing the same MTLSharedEvent) without a CPU wait. Mirrors the recently-added Vulkan add_wait_semaphore (#9461) and DX12 add_wait_fence / add_signal_fence (#9463).

Signals are encoded after wgpu's own completion signal, so foreign waiters observe the submit as done. Waits are encoded onto a dedicated internal command buffer committed before the submit's user CBs.

Metal allows independent command buffers in the same queue to overlap on the GPU, so a wait CB does not strictly gate subsequent user CBs that share no Metal-tracked resources with it. Single-stream pipelines often serialize anyway because the GPU has no concurrent work to fill the slot, but mixed workloads (decode + compute + render) can race past the staged waits.

For strict ordering, callers can opt into metal::Queue::enable_strict_event_sync(), which routes staged waits through a per-queue relay MTLSharedEvent. Every begin_encoding pre-encodes a wait on the relay at the value the next submit will signal; every submit drains the staged foreign waits and then signals the relay, releasing all CBs encoded since the previous submit in lockstep. Costs one extra encodeWaitForEvent per CB plus one extra internal CB per submit on that queue.

Testing
Explain how this change is tested.

Squash

Squash

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
• Validation and feature gates are in place to confine behavioral changes.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.