V1.0.0 branch 25023 fix

[domichae-amazon]

Fixes project-chip#25023 on the v1.0.0 branch.

---

Lock the SDK before interacting with it.

[Problem]

The Matter SDK assumes that the client will take a lock on the SDK prior to
interacting with any APIs. There is 1 Android function and several iOS functions
that do not take the lock prior to interacting with the SDK APIs.

There are also some functions that invoke the Matter SDK in a way that may
result in out-of-order callback invocation (e.g. the conceptual "started"
callback may be invoked after the conceptual "ended" callback).

[Solution]

Create utility functions that help ensure that the Matter SDK is invoked safely
and that callbacks are delivered in the correct order.

[Testing]

Performed local, manual testing with the 'tv-casting-app' example on iOS against
a Raspberry Pi running the 'tv-app'. Ran the certification test in the
'tv-casting-app' on iOS against the same Raspberry Pi.

[sharadb-amazon]

Would it be cleaner if we just entirely skipped storing these callbacks in the _readSuccess/failureCallbacks property?

[domichae-amazon]

It would, but unfortunately it gets a little gnarly because the Read-style APIs take a ReadResponseSuccessCallback and ReadResponseFailureCallback which are void (*)(void * context, T responseData) and void (*)(void * context, CHIP_ERROR err), respectively.

When I updated the APIs with Response callbacks to avoid the Dictionary lookup, I was relying on the fact that those APIs take a std::function for the response callback and Objective C lambdas with captured variables can be implicitly converted to std::functions (this is necessary because we need to capture the clientQueue and the response callback). Unfortunately, Objective C lambdas with captured variables can't be implicitly converted to std::functions so you can't easily keep around a reference to the callback function or client queue.

If we find a solution for the Read-style methods, though, then we should be able to extend that to the Subscribe methods pretty easily and cut down on a lot of the boilerplate in the CastingServerBridge.