Lack of consideration for forwards compatibility of bit patterns

[jrtc27]

The capability bit pattern, and related patterns like the input to ACPERM, is effectively ABI, and so any additions must be done in an ABI-compatible manner. That means that any extensions which add to these bit patterns must do so in a way that means existing bit patterns are unchanged in their meaning. As some examples:

1. Adding Load Mutable on top of Load should be done such that existing bit patterns with Load now mean Load+Load Mutable (i.e. either the ACPERM bit is negated or the bit in use was defined as RES1, to borrow Arm's terminology, with equivalent requirements for the compressed AP field in the actual capability)
2. Adding type-based sealing can have existing bit patterns not include (un)seal permission, since the expectation is that they're a separate set of capabilities you opt into using, not something existing capabilities in your program need to support
3. Adding type-based sealing should be done such that existing bit patterns are not sealed with a type
4. Adding capability levels should be done such that existing bit patterns continue to be able to load/store everything they already could (but possibly not some higher-level capabilities that other parts of the system have opted into using; this is less clear)

The entire spec needs to be carefully checked to ensure that the extensions defined on top of the base are done in this manner, and that there is enough flexibility to be able to add future extensions in such a compatible manner. Otherwise there is a significant risk that, once standardised, we will be unable to extend the capability format without making the set of extensions part of the ABI, which would be disastrous for deployment in the application core space.