[rom_ctrl] Options to speed up ROM verification

Nobody has claimed this yet.

### Description

Related to #30389 , I investigated how long it will take to verify the ROM on the chip and if there are easy ways to accelerate it.

For the current implementation, the verification of the 32 KiB ROM takes around 35k clock cycles. Per KMAC block (1088 bits of data + ECC), this amounts to 116 clock cycles, of which 96 clock cycles are due to the KMAC HWIP processing, and 20 clock cycles are for moving the data + ECC from ROM to KMAC.

If we now, increase the ROM by 6x to have 192 KiB of ROM, we'll end up with 210k clock cycles which will amount to roughly 1.4% of the budget we have for the entire secure boot. We could do the following things to speed this up:
1. Not hash the ECC bits but just the data (from a security viewpoint, the ECC bits don't need to be hashed as pointed out in the Security WG Meeting on 2025-11-06). This would reduce the verification time from 210k clock cycles to 178k clock cycles (-15%).
2. Option 1 + use a 64-bit ROM to fully exploit the 64-bit channel on the application interface of the KMAC hardware IP. This would reduce time spent for moving the data from ROM to KMAC. The total cycle count would go down to 153k clock cycles (-27%).
3. Option 1 + switch from cSHAKE256 to cSHAKE128. This would somewhat lower the security of the hash but on the other hand hash more data per block. Expected cycle count 153 k clock cycles (-27%).
4. Option 1 + 2 and 3: 128k clock cycles (-39%).

**Update**: For CNSA 2.0 compliance, we'll have to switch from cSHAKE256 to SHA3-384 for the ROM integrity verification. This parameter set has a lower rate, meaning more blocks and cycles are needed. The number of cycles will go up to 259k. Again, one would have two options to speed things up:
1. Not hash the ECC bits but just the data (from a security viewpoint, the ECC bits don't need to be hashed as pointed out in the Security WG Meeting on 2025-11-06). This would reduce the verification time from 259k clock cycles to 217k clock cycles (-16%).
2. Option 1 + use a 64-bit ROM to fully exploit the 64-bit channel on the application interface of the KMAC hardware IP. This would reduce time spent for moving the data from ROM to KMAC. The total cycle count would go down to 192k clock cycles (-26%).

The issue names no files or tests; start by locating the ROM integrity-verification entry point and the ROM-to-KMAC data path, then confirm the current cycle-count baseline. Done would require an agreed option, its security and compatibility rationale, and measurements showing the expected cycle reduction.

Written by the indexing model from the issue text.