[rv_core_ibex] Suggested Address Translation improvements

### Description

**Background:**

The rv_core_ibex logic that wraps the portable Ibex core provides not just TL-UL compatibility for the OT project but also some additional functionality including a simple address translation layer. This translation scheme was originally created to allow one ROM image from a set of images at different physical addresses to be mapped to a fixed logical address, with all images having been built to run at that fixed address.

With Darjeeling the number of regions has been increased to implement the required ROM patching functionality for the second boot ROM.

Darjeeling presently extends the original two regions _per access port_ to 32 regions per port. There are two ports - Instruction accesses and Data accesses - but in order to present consistent views to both Instruction fetches and Data accesses, the same information is programmed into the set of 'D' registers as the 'I' registers.

Additionally, each of the 2 x 32 regions has its own 'EN'able register that holds just a single bit specifying that the region is valid. This is rather wasteful of address space and has limited extensibility.

**Proposal:**

Replace the sets of 'I' and 'D' registers with a single set of configuration registers that is accessible to both ports, and include two enable bits which may be stored in the 'remap' register:

```
ADDR_MATCHING[n] 31:0 - Matching address region for both Ibus and Dbus.
REMAP_ADDR[n] 31:2 - Remap address after a match has been made.
1 - Enabled for Data accesses
0 - Enabled for Instruction accesses
```

This reduces the amount of address space used and allows a larger number of remappings to be accommodated for a given number of configuration registers, since the normal use case will require a remapping to be presented on both the Instruction and the Data buses.

**Caveat:**

Since this mechanism is already used within Earl Grey and ROM code, it may be necessary to treat the first couple of regions in a manner that is backwards-compatible, depending upon the amount of existing software, hardware and tooling etc that already depends upon their specification/behavior.