Deprecate the use of "Key Expiration Time" packets (type 9) in V5 sigs
There are two distinct methods of calculating expiration dates in the standard, only one of which is meaningful in a given context. For V5 signatures, we should deprecate the more error-prone of these methods and extend the meaning of the simpler one to cover all use cases.
The simpler method is the "Signature Expiration Time" subpacket, which stores the expiration date of a signature as the number of seconds since the "Signature Creation Time" subpacket of the signature (i.e. the same packet). This method is used for third-party sigs.
The more error-prone method (see !113 (merged)) is the "Key Expiration Time" subpacket, which stores the expiration date of a (sub)key as the number of seconds since the "Key Creation Time" subpacket of some other packet - meaning that absolute expiration dates can only be calculated by reference to multiple packets. This method is used for self-sigs.
We should instead use "Signature Expiration Time" subpackets for all kinds of signatures, and where necessary define the "expiration date" of a (sub)key as the date at which it becomes unusable due to lack of valid self-sigs. This means that a subkey effectively expires on the date that its last valid sbind expires, and a primary key effectively expires when is last valid UID expires.
To fix this in the text, we would state in 5.2.3.6 that "Key Expiration Time" subpackets MUST only appear in V4 sigs, and that V5 sigs MUST use the "Signature Expiration Time" subpacket instead. For further clarity, we can add an explanatory note with the gist of the above argument to 5.2.3.3.
[ edited for clarity following discussion below ]