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 rs-soroban-sdk#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 (stellar/rs-soroban-sdk#1570) and type alias limitations (stellar/rs-soroban-sdk#1857):

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

What

Add a new SCSpecEntryV2 entry that pairs an 8-byte id with a body union reusing the existing V0 entry bodies (function, UDT struct/union/enum/error enum, event), exposed as a new SC_SPEC_ENTRY_V2 arm of SCSpecEntry. Add a SCSpecTypeUDTV2 reference type carrying the referenced type's name and the id of the entry it refers to. A SC_SPEC_ID_LEN const defines the id length. The id is the truncated SHA-256 of the fully qualified name of the item the entry describes.

The change is purely additive: the existing V0 entry arms, the V0 body structs, and the existing SCSpecTypeUDT reference are unchanged, so existing specs continue to decode.

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. An id derived from the item's fully qualified name identifies it exactly, so every entry has a unique identifier and a reference is known to refer to one entry precisely, even when entries share a name.

The id lives at the top level of the entry — beside the body, not inside it — so every entry kind gets an id the same way, functions and events included, and the body structs stay unchanged.