[boot_flow] Self-authenticate boot images for faster boot flow

### Description

**Summary**

We can reduce signature verification during boot time to single KMAC operation by self-authenticating boot firmware. Depending on the number of boot stages, this cost might be multipled by 2 or more.

**Details**

To simply describe the idea, let me represent (msg, sig) to denote an image of a boot stage. Normally, each stage would run SigVerify(pub_key, msg, sig) to check authenticity of the next boot stage image, where SigVerify is the verification algorithm of the underlying signature scheme. Running SigVerify might be costly. For instance, a verification takes about 3ms and 13ms for RSA and SPHINCS+ respectively.

We can speed up this verification considerably by adding authentication tags next to boot images and verifying these symmetric tags instead of actual public-key signatures. The tags would be generated by KMAC with a symmetric key derived by Keymgr and these keys would be unique to each device.

Following the same notation, when the boot image is of the form (msg, sig), we can add a third field to this tuple to get (msg, sig, tag). During boot, we can quickly verify KMAC(keymgr_generated_key, msg || sig) = tag and if that check holds, we can skip SigVerify(msg, sig). The tag would be generated after the fresh update and computed directly by the OT device itself.

**Benefits**

1. Slower full RSA/SPHINCS+ signature verification would be replaced with faster KMAC operations. The idea is agnostic to signature scheme (which also means one could even go with slower PQ signature schemes in the future).
2. This could be repeated for each boot stage.
3. Existing HW already supports this flow. Keymgr can handle the generation of the symmetric key and use the sideload interface to pass the key to KMAC. This flow handles key in two shares. I think no RTL change is needed.
4. The symmetric key does not need to be static, and it can be regularly rotated (either through update, or by providing further salt values as part of the boot image). Each rotation only costs 1 more SigVerify.

**Downside**

1. Keymgr would need to come online earlier during boot flow, in order to generate a symmetric key for KMAC. Furthermore,
ROM code needs to be updated in a way that this verification is orchestrated between KMAC and Keymgr. (Or alternatively, one might skip this idea for ROMExt verification and use it for other boot stages).
2. From security perspective, one also needs to be concerned about potential side-channel leakage of the key used to verify SW images. If this key is recovered by the adversary, it allows loading malicious boot images.

There would be some further aspects to discuss about this idea, such as how to update manifests and where to add such tag field, or whether there should be an OTP bit to enable/disable this feature, but I think it might come down to whether 1) we need a speed-up in the boot flow, 2) whether we can secure the symmetric key against SCA.

ccing for futher discussion: @johannheyszl @jadephilipoom @gdessouky @moidx @timothytrippel @sameo

No files, tests, or entry points are named. Start by tracing the ROM code, Keymgr, KMAC, manifests, and boot stages referenced in the proposal; done would require an agreed implementation scope and security requirements.

Written by the indexing model from the issue text.