[moetemp]

What changed?

This PR adds the Stream runtime of temporalio-streams to the C bridge, for the .NET SDK.

• Five functions in src/streams.rs. temporal_core_stream_runtime_new builds the runtime of a kind (memory or redis) from its encoded config. temporal_core_stream_call runs a method on Core's Tokio runtime and calls back with the result, and the existing TemporalCoreCancellationToken cancels it with code 1. temporal_core_stream_call_sync and temporal_core_stream_call_static answer at once.
• Inputs are TemporalCoreByteArrayRef. An empty one may have a null pointer.
• A panic in a call answers as INTERNAL, since a panic can't cross the C ABI.
• A call that ended before its cancel took effect still gives its result, since its effects happened. Outputs are TemporalCoreByteArray, which the caller frees with temporal_core_byte_array_free. A failure gives the gRPC code, the message and the encoded StreamErrorDetails.
• Two features, both off by default. streams adds the optional path dependency on temporalio-streams. streams-redis adds the optional dependency on temporalio-streams-redis.
• The functions exist in every build, so the header and .NET's Interop.cs don't change with the features. Without streams, a runtime fails to build with "This build has no Stream runtime". Without streams-redis, the redis kind fails the same way.
• temporalio-streams-redis isn't on crates.io yet. So the workspace patches it to R4 (temporal-community/sdk-streams#4) by git rev, and patches that crate's temporalio-streams and temporalio-common to this workspace's copies. Each cargo call in this workspace now fetches that git repo, with the features off too.

Depends on #225 (K15). Review lane is the Rust reviewers.
Part of the Brook review series.

Spencer, can the C bridge take this optional dependency on the community Redis crate, behind streams-redis and off by default, as we discussed? Once the crate is on crates.io, the git patch goes and it's a plain crates.io dependency. The other choice is a .NET-owned wrapper cdylib that links this bridge as an rlib, but that renames the native library and changes much of Interop.cs.

Why?

.NET reaches Core only through this bridge, and a second native library couldn't share Core's Tokio runtime or its meter. So the .NET SDK's Stream runtime has to be in this cdylib. The official .NET build turns both features on, and other builds stay as they are.

How did you test it?

cargo clippy -- -D warnings and the bridge's streams tests pass with no features, with streams, and with streams,streams-redis, and the header is the same after each build. The tests call temporal_core_stream_call on the memory runtime through a callback, check a failure's code and details, cancel a 30 s read through a token, and call the sync and static functions. cargo doc passes with every feature.

[moetemp]

Parked. No SDK uses the Stream runtime through the C bridge yet. The branch stays, and this layer comes back with the .NET port.