Specify behaviour for reserved permission encoding

[Timmmm]

Fixes #47

[arichardson]

I think this makes a lot of sense especially if we consider forward compatibility.

[andresag01]

@Timmmm @arichardson @tariqkurd-repo : What do you think would happen if executing CBuildCap to tag a cap that has permissions set to a reserved value? Options include:

1. Set the permissions of the output cap to 0 (i.e. no permissions)
2. Set tag 0 for the output tag

I would prefer (2)!

[jrtc27]

Any kind of reserved input should always be untagged in the output. Anything else sounds like trouble.

[jrtc27]

The way this is worded forbids an extension later assigning meaning to it (yes, this is non-normative text, but you still don't want it to be contradictory)

[Timmmm]

Good point. Would it be ok if I change it to It is currently not possible... <<CGETPERM>> will currently interpret it... This may change in future..

[arichardson]

Maybe something like this still allows for future extensibility:

If the permission encoding has reserved bit patterns (e.g. the format for XLENMAX=32 with {cheri_base_ext_name}
xref:cap_perms_encoding32[xrefstyle=short]) then it is not possible for a tagged
capability to have this value since <<CANDPERM>> will never create it. However, it is
possible for untagged capabilities to have it in which case <<CGETPERM>> will interpret it
as if it were 0b0000 (no permissions). Future extensions may assign meaning to these bit patterns for which <<CANDPERM>> is allowed to report a non-zero value.

[Timmmm]

Updated based on @arichardson's suggestion.

[arichardson]

Lgtm, @jrtc27 are you happy with this wording?

[andresag01]

It looks good to me, but we still need a comment about CBuildCap. Perhaps its best to do that as a separate PR.