RFC: Optional dotNsIdentifier and permissioned external-account access

[valentinfernandez1]

Summary

The account, signing, and statement-store calls that operate on a product account take a
ProductAccountId { dotNsIdentifier, derivationIndex }, and dotNsIdentifier is optional.

• Omit it and the call addresses the caller's own product. The host resolves the domain from the
  authenticated caller, so the common case only needs a derivationIndex.
• Supply a domain that names a different product and the call is cross-product access, gated behind a
  new ExternalAccount remote permission. Like ChainSubmit and StatementSubmit, it is triggered
  implicitly the first time a product makes such a call, and the host accepts or rejects based on the
  grant.

// Own account, the common case
await truapi.account.getAccount({ productAccountId: { derivationIndex: 0 } });

// Another product's account, requires the ExternalAccount permission
await truapi.account.getAccount({
  productAccountId: { dotNsIdentifier: "another-product.dot", derivationIndex: 0 },
});

Host-side enforcement of the ExternalAccount permission lives in the host and is not part of this
change. This PR defines the wire types, the permission variant, and the trait documentation.

[valentinfernandez1]

Keeping as draft for now as this is a big breaking change and we need to settle on the best versioning strategy for this

[valentunn]

The dotNsIdentifier is present there intentionally: some products are interested in requesting accounts of other products

Hard NO from my side

[valentinfernandez1]

Thanks for the feedback @valentunn, I was not aware of this requirement since in general we want per product isolation.

Still part of my design still applies, I invite you to read though the issue as this is not necessarily removing it but rather removing it from these calls and creating explicit permissioned calls for products that want to access the user's account in another product.

So if a product wants to access an account that is not from its on product it must be first explicitly be granted permission by the user

[valentinfernandez1]

I will refactor this draft though as I realized that there is a simpler way to approach this by keeping the dotNsIdentifier (maybe make it optional) and if the dotNsIdentifier is different from the one on the current product the host can accept or reject the call depending on whether the user has provided ExternalAccountAccees permission (new permission to be added here)

[valentinfernandez1]

Refactoring is done, I have also updated the title and description of this Draft to reflect the updated behavior