Update CFPA's IMAGE_KEY_REVOKE if bootleby and both slots have a newer revocation ID

Signed images pack a 16-bit uniary revocation ID into the signer's certificate serial number. NXP ROM compares this value against CFPA's IMAGE_KEY_REVOKE. Signed images are only considered valid if their revocation IDs exactly match IMAGE_KEY_REVOKE or are the next valid value (IMAGE_KEY_REVOKE+1 in uniary).

NXP ROM does not update IMAGE_KEY_REVOKE on its own but leaves it up to the booted image. This avoids a scenario where a valid, signed image is flashed that has IMAGE_KEY_REVOKE+1 but that image fails to boot. When using only the NXP ROM, this would require external intervention to recover (assuming the ISP or SWD interfaces are even enabled).

With bootleby, we already use A/B slots. Assuming the main image only updates one slot at a time (i.e. it never flashes the slot it is running from), then the only way we end up with a newer revocation ID in both slots is if bootleby and at least one of the slots has booted successfully. If that's the case, bootleby could go ahead and update IMAGE_KEY_REVOKE.

Concretely, if bootleby's own revocation ID and both slots' revocation IDs all match and are the next valid IMAGE_KEY_REVOKE, bootleby should go ahead and update IMAGE_KEY_REVOKE.

Start by tracing how bootleby obtains its revocation ID, validates both A/B slots, and updates CFPA's IMAGE_KEY_REVOKE; the issue names no files or tests. Done means IMAGE_KEY_REVOKE is updated only when bootleby and both slots have matching IDs equal to the next valid value.