Encode contract spec XDR at const evaluation time

[leighmcculloch]

Note

Part of a stack of PRs that must merge in this order.

A first group of PRs deliver const-encoded contract specs, so that contract specs are produced at compile time instead of at proc-macro execution time. This provides the foundation for the capability to construct the specs from information that is not known at proc-macro execution and only known at compile time, like the fully qualified name of a type:

1. Add borrowed Ref variants of generated types rs-stellar-xdr#560
2. Add const XDR serialization on View types rs-stellar-xdr#562
3. Encode contract spec XDR at const evaluation time #1965 ← this PR

A second group of PRs deliver fully qualified type names in contract specs. Instead of a type having the name Context it will have the name soroban_sdk::auth::Context. Qualified type names make it possible to uniquely identify types in the spec, even when they have the same name. This resolves several problems with contract specs the type identify problem (#1570), type aliases limitations (#1857), and optimise spec shaking data section size (#1978):

1. Widen user-defined type name limit stellar-xdr#312
2. Regenerate with widened UDT name limit rs-stellar-xdr#566
3. Qualify user-defined type names #1970
4. Update stellar-xdr to 28.0.0 rs-stellar-rpc-client#108
5. Patch xdr and spec crates to support long type names stellar-cli#2674

What

Change when and where contract spec XDR is encoded. Before, the proc-macro encoded the spec and embedded the resulting bytes as an opaque literal in the generated code. After, the proc-macro constructs a ScSpecEntryView over static data and the encoding happens at const evaluation time while the generated code compiles, using the new const XDR encoding support.

Example

Why

The spec stops being an opaque blob and becomes a value: readable in cargo expand, referenceable by other generated code, and no longer only inspectable by decoding bytes back out of a built wasm. It is also the foundation for connecting type IDs across types in a future change.

All 43 test contracts' contractspecv0 sections are byte-identical to main, so nothing downstream observes a difference. 42 of the 43 whole wasm binaries are identical as well; in the one that differs, two internal non-exported functions swap emission order — the export, type, data and metadata sections are all byte-identical.

[leighmcculloch]

TODO: Find a way to do the sha256 marker generation in a const context without writing our own sha256 impl.