Proposal for C# SDK performance

The BSATN codegen for c# often generates pattern like new(new()) to emulate rust's variant types, and wraps certain value types into reference classes, such as Timestamp and EnergyQuota.

Similarly, many allocations for encoding and decoding of messages can be made once and reused, or at least pooled to avoid allocations.

A great deal of GC overhead and pressure can be removed by refactoring codegen to emit high-performance C#.

One benefit of this is to gain support for Burst compilation and ECS in Unity, as they do not allow reference types to be used at all.

Proposal should also look at the way updates are processed by SDK clients and look at a way to send the matching memory layouts directly from rust. Right now an intermediate client-side processing pass using a temporary hashmap is required to combine matching inserts/deletes into updates.

Start by locating the C# BSATN code generator and the SDK client update-processing path. Measure allocations from generated value wrappers, encoding and decoding, and temporary update processing; done requires a defined high-performance design that supports Burst/ECS constraints and reduces the described allocation and intermediate-processing overhead.