Cross-product interactions

Part of #591. Membership is carried by the Product permissions label and by this issue's
sub-issues.

Absorbs the requirements previously stated as REQ1, REQ2, REQ4 and REQ6.

What has to be true

A product can read another product's state when trusted. Products that work on the same
things keep separate copies of the state that describes them, because host storage is sealed
per product and per device. State two products both describe diverges the moment one changes
it, and neither can reconcile it. The product that owns the state also has no way to say who
may read it.

A product can use another product's context when trusted. Trust between products is
declared in the product manifest, and nothing in the core or the generated client reads that
declaration, so cross-product access is never granted — only prompted, or refused. The core
also answers the same cross-product request differently depending on which call carries it.

Blessed products ship pre-activated. A user opening the release already has them,
reachable from where they belong, with no add, install or discover step.

Blessed products hold remote permissions without prompting. Declared domains, WebRTC, and
chain transactions, preimages and statements, without re-asking every run. Which products are
blessed is compiled into the host binary, so the set cannot change without shipping a host,
and a build deployed under a test name is not the build the user gets.

Reading and enforcing the product manifest is what the first two rest on. It works today only
through hacks; replacing them with real TrUAPI methods is the centre of the release.

Gap

Consent and revoke is unspecified. Both trust requirements depend on it.