Rework register file's "zero" register

[stnolting]

This PR reworks the handling of register x0 (= "zero"), which is always returns zero.

We do not want to implement AND-gates to set the register source operands (rs1 & rs2) to zero when reading from register x0 since this would cost ~64 LUTs and would also increase the critical path. Hence, register zero is part of the register file and will also be mapped to the register file-absorbing block RAM - so register x0 is a physical register. We do not want to rely on BRAM initialization to ensure that x0 is always zero. Thus, a special logic is required.

Pre-PR

The current register file checks all write accesses if they target register zero. For any write access to this register, the actual read data is set to zero. This increases the critical path (register file -> ALU -> register file) as an additional logic level is required. Furthermore, the very first instruction of a program has to write to x0 to make sure it is cleared. Currently, this is ensured by the CPU start-up code crt0.S. However, this is not portable as users might use custom start-up codes.

Post-Pr

The CPU control ensures that register x0 is set to zero by forcing a zero-write to this register. The additional logic to flush the register file write data to zero is removed. This shortens the critical path and also reduces area costs.

ℹ️ For implementations using a custom register file architecture (where x0 is actually hardwired to zero) the hardware-based initialization can be disabled by setting reset_x0_c := false (VHDL constant in neorv32_package.vhd).

---

This PR also fixes a synthesis/simulation warning regarding unconnected pmp_* signals.