Add a ref-counted decoded bytecode cache backing so bytecode cache
materialization can create fresh script or module records from a shared
decoded sidecar without passing around one-shot raw blob ownership.
Keep that backing in ExecutableBacking for records materialized from
bytecode cache sidecars, so the immutable decoded data stays alive for
as long as the installed record needs it.
Cover the shared backing path with a bytecode-cache test that
materializes and runs two scripts from one decoded backing.
Introduce ExecutableBacking as the state machine for how a Script or
SourceTextModule executable is backed. Keep construction and transitions
private to the owning record types so transient cache-generation states
cannot be created directly.
