Allow built-in composite types to be storable

[turbolent]

⚠️ Depends on #2878

Description

• Allow built-in composite types to be storable

• Allow built-in composite values to be storable.

  As discussed in https://discord.com/channels/613813861610684416/1108479699732152503/1164334273684324402, allowing CompositeValue.Storable to determine if the value's type is storable, by getting the CompositeType for the value, is tricky, as the function is called by atree, and it does not provide access to an Interpreter easily.

  Allow getting root interpreter from interpreter storage, which is ugly and works. If you have any better ideas, please let me know – I don't like this, but couldn't find another easy workable solution.

  For now this is tech-debt: Eventually in Stable Cadence (which cannot be used, we need this feature on master), we'll have fewer CompositeValues with built-in CompositeTypes that are non-storable (e.g. currently AuthAccount), and we might find a better alternative to this approach later. At least for now this unblocks the work on the EVM integration in flow-go.

  Finally, allow built-in composite values to be storable, by checking for built-in types, if the composite value's composite type is storable (some are not, e.g. AuthAccount). Only check built-in types, because non-built-in composite values/types are always considered storable.

---

• Targeted PR against master branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work
• Code follows the standards mentioned here
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[turbolent]

As mentioned above, this adds some tech debt. After discussing implementation approaches for the Flex contract with @ramtinms and @janezpodhostnik, we realized that the Flex contract does not necessarily need to be a built-in, so this PR is no longer needed