Announce spec shaking v3 to the SDK

[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 View 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 rs-soroban-sdk#1965

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 (stellar/rs-soroban-sdk#1570), type aliases limitations (stellar/rs-soroban-sdk#1857 stellar/rs-soroban-sdk#1063), and optimise spec shaking data section size (stellar/rs-soroban-sdk#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 rs-soroban-sdk#1970
4. Update stellar-xdr to 28.0.0 rs-stellar-rpc-client#108
5. Reduce fully qualified UDT names in contract info output #2674

A third group of PRs use those qualified names to shake specs by reachability, so that the markers a contract carries shrink to the few entries a spec never names:

1. Shake specs by reachability, not markers rs-soroban-sdk#2043
2. Announce spec shaking v3 to the SDK #2720 ← this PR

What

Patch in the soroban-sdk change that shakes specs by reachability (stellar/rs-soroban-sdk#2043), announce SOROBAN_SDK_BUILD_SYSTEM_SUPPORTS_SPEC_SHAKING_V3 to the SDK alongside the existing v2 var, and shake any wasm recording version 2 or newer rather than exactly version 2.

Why

The SDK on that branch requires the v3 var, because from that version most types carry no marker and the build system has to shake them out by following the references to them, so a build system announcing only v2 would keep every type it found no marker for. The v2 var stays set because it remains true of this CLI and a contract on an older published SDK looks for that var alone and refuses to build without it, and a v2 wasm shakes correctly under the v3 rules anyway, since a marker there is only ever carried by an entry that is used and the types that carried one are named by the entries using them.

Known limitations

Contract fixtures built by the tests resolve soroban-sdk from crates.io rather than through the workspace patch, so they cover the v2 path and the SDK's own end-to-end test contract covers v3. The [patch.crates-io] git revisions are replaced with published versions once stellar/rs-stellar-xdr#566 and the soroban-sdk stack land and release.