Preserve ordered delivery for concurrent subject sends

[mikamikasuki]

Description

Closes #61.

Concurrent calls to send can update a subject's state in one order but deliver snapshots to consumers in another. This can leave subscribers with different event orders, or make a current-value or replay subscriber finish with a value older than the subject's latest state.

This change queues each delivery while holding the subject state lock, then drains the FIFO queue after releasing that lock. A single drainer preserves the state-update order across all six subject variants while keeping consumer resumption outside the subject and queue locks, so cancellation handlers can safely re-enter the subject.

The change also adds concurrent-send ordering and cancellation-handler regression tests and updates the Unreleased changelog.

Validation

• swift build passes.
• A standalone stress harness observed no ordering or stale-value mismatches across 200 rounds for each of the six subject variants; 1,000 cancellation-handler/send races completed.
• swift test --filter AsyncSubjectConcurrentSendOrderingTests could not run on this host because XCTest is unavailable (no such module XCTest). The added test source was typechecked separately.

Checklist

• this PR is based on the main branch and is up-to-date
• the commits inside this PR have explicit commit messages
• unit tests cover the bug fix
• the feature is documented in the README.md if it makes sense
• the CHANGELOG is up-to-date

[twittemb]

Closing in favor of #62, which addresses the same concurrent subject-send ordering issue. We will keep #62 as the implementation to review and merge: #62