Add ids to contract spec entries

[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

A second group of PRs deliver ids on contract spec entries and in spec references. Every entry carries an 8-byte id hashed from the fully qualified name of the item it describes, and a reference to a user-defined type carries the id of the entry it refers to, so references stay unambiguous even when items share a name. This resolves the type identity problem (#1570) and type alias limitations (#1857):

1. Add ids to contract spec entries stellar-xdr#313
2. Regenerate with ids on contract spec entries rs-stellar-xdr#568
3. Add ids to contract spec entries #1998 ← this PR
4. Adopt spec entry ids and id-based reference resolution stellar-cli#2677

What

Emit every contract spec entry — functions, user-defined types, and events alike — as the new ScSpecEntry::V2, which stores an 8-byte id at the top level of the entry next to the unchanged V0 body. The id is the truncated SHA-256 of the item's fully qualified name, computed at const evaluation time by a const SHA-256 in the SDK: a user-defined type hashes module_path::TypeName via the spec_type_id const fn the derive macros generate on it; a function hashes module_path::ContractType::fn_name; an event hashes the event type's module_path::TypeName.

Every reference to a user-defined type is emitted as ScSpecTypeUdtv2, carrying the referenced type's name and the id of the type's entry. The reference takes its id from the Rust type it refers to by calling that type's spec_type_id, so a reference and the entry it refers to cannot disagree, and two references are known to refer to the same type, or to different types, even when the types share a name (Flag, Flag2).

soroban-spec-rust and the spec-shaking filter treat a v2 entry as its body plus an identity; generation and filtering work from the body.

Why

A bare name cannot tell two items apart: two crates, or two modules of one crate, can each define a Flag, and a spec that names both simply Flag cannot say which is which. The id hashes the fully qualified name — the module path where the item is defined, then its own name — which only the compiler knows, so it is unique within a build across the crates that make it up. Storing the id on every entry gives each entry a unique identifier, and a reference carrying an id resolves to exactly one entry by matching ids.

Taking a reference's id from the Rust type also makes a reference written through a type alias carry the id of the type the alias names, which a name-based reference could never do.

Known limitations

core::any::type_name is not yet callable in const contexts on stable Rust, so the fully qualified name is assembled from module_path!() expanded where the item is defined, combined with the item's ident — the same string type_name reports. Specs emitted by this SDK use the new entry and reference types, so tooling built against older XDR cannot decode them; specs produced by earlier SDKs continue to decode with the new XDR.