fix(proto-plus): make Marshal thread-safe and handle race conditions

[chalmerlowe]

Thread-safe Marshal Initialization

Problem

A RuntimeError saying dictionary changed size during iteration can occur randomly in BaseMarshal.get_rule. This happens because one thread is reading the _instances dictionary while another thread is adding a new instance to it. This is common when using features like Firestore's on_snapshot in a background thread.

Solution

1. Thread-safe instance creation: Applied a locking mechanism in Marshal.__new__. It uses a technique called "double-checked locking" to make sure only one thread creates a new instance at a time without slowing down normal reads.
2. Copy-on-Write Pattern: When a new instance is added, we make a copy of the existing instances dictionary, add the new one, and then replace the dictionary atomically. This ensures that threads iterating over the old dictionary are not interrupted.
3. Defensive Attribute Access: Added safety in BaseMarshal.get_rule to avoid trying to read rules from an instance that has been registered but has not finished initializing yet.

Notes to Reviewers

• The Copy-on-Write pattern allows us to avoid locking during reads (which are very common), keeping performance high while fixing the race condition.
• A new test file test_marshal_thread_safety.py has been added to cover these concurrency scenarios.
• Some portions of files in this package were reformatted automatically by the code linters.

Fixes#15100

[gemini-code-assist]

Code Review

This pull request introduces thread-safety improvements to the Marshal class, implementing a threading lock, double-checked locking, and copy-on-write dictionary updates to prevent race conditions and dictionary mutation errors during iteration. It also adds safety checks for uninitialized instances and a comprehensive test suite. The review feedback recommends using unittest.mock.patch.dict in the tests to safely modify Marshal._instances and avoid potential test pollution if a test fails.

[parthea]

LGTM