[sram_ctrl] Prevent software from initializing SRAM_CTRL with deterministic keys

@vogelpi is already working on this.

Since Jun 24, 2025.

### Description

In the context of #27381, we have been discussing that we should prevent software from initializing SRAM_CTRL with deterministic keys. Currently, the module exposes two separate control fields
- CTRL.INIT: causes the memory to be initialized with whatever scrambling key is available, the duration of this operation depends on the memory size (16k cycles for Darjeeling main SRAM, 32k cycles for Earlgrey main SRAM).
- CTRL.RENEW_SCR_KEY: requests a new scrambling key. This takes around 800 clock cycles if OTP has entropy available but it may take much longer if OTP_CTRL first needs to refresh entropy. After reset, the default scrambling key is based on a secret netlist constant.

The following two options have been discussed to prevent software from using SRAM_CTRL with a deterministic scrambling key:
1. Combine the two settings, i.e., INIT would only be possible after RENEW_SCR_KEY. The additional delay for the wiping (due to requesting a new scrambling key) may be critical for escalation use cases where one wants to wipe the SRAM contents with the current key (assuming it's an ephemeral one).
2. Like in OTBN, the INIT could be changed to first wipe with whatever key is there, renew the scrambling key, and then perform a second wipe with the scrambling key. This would allow to wipe the SRAM immediately (relevant for escalations) while at the same time guarantee that after the operation finishes, the content is initialized with a non-deterministic key. The disadvantage of this approach is that wiping now takes twice the number of clock cycles.