[spi_device,rtl] Handle SRAM integrity error output decisively

[hcallahan-lowrisc]

Description

opentitan/hw/ip/spi_device/rtl/spid_readsram.sv

Lines 344 to 347 in 39f9a9e

	// TODO: Handle SRAM integrity errors
	sram_err_t unused_sram_rerror;
	assign unused_sram_rerror = sram_m2l_i.rerror;

e.g.

1. Update comment to explain decision to leave unconnected
2. Create an alert from this signal
3. ...

[a-will]

Just a note: If we make this an alert, we'll also need to have firmware completely initialize the accessible regions of the RAM, including "unused" portions of accessible regions, and document this in the programming guide.

Hosts may choose to read unused areas of the SFDP array, for example, and unless those are initialized to a known value, the alert could trigger from innocent behavior.

[msfschaffner]

Given that this is not a security IP, I am not sure this needs to be a fatal alert.
On the bus side, we just send back a tlul bus error in case the parity of a SPI_DEVICE SRAM access is wrong.
We could potentially trigger a regular error + interrupt if this happens.

[msfschaffner]

Discussed with @a-will and we think it is fine to put this in the backlog for now, given that this is not a security IP.