Trap Return with activated Branch Prediction results in an unintended instruction retire

Nobody has claimed this yet.

## Observed Behavior

Just by simply executing the simple system with hello world I found this issue. Enable the WritebackStage as well as the BranchPredictor. Then execute the program with any simulator.
In the instruction logfile, something odd appears:
```
5368 2680 00100338 6161 c.addi16sp x2,80 x2:0x00137f90 x2=0x00137fe0
5370 2681 0010033a 30200073 mret
5378 2685 0010033e ea1ff06f jal x0,100462 x0=0x00000000
5380 2686 00100462 84ca c.mv x9,x18 x0:0x00000000 x18:0x00000000 x9=0x00000000
```

It seems that after `mret` the next consecutive instruction is loaded into the pipeline before the execution is continued at the `epc` value. This can also be seen in the waveform:
The issue seems to be that the signal `instr_skid_en` is set since there is no special case implemented to detect that this is a trap return.

Is this a bug or is this behavior intended?

## Expected Behavior

The intended behavior would result in the following instruction trace:
```
5368 2680 00100338 6161 c.addi16sp x2,80 x2:0x00137f90 x2=0x00137fe0
5370 2681 0010033a 30200073 mret
5380 2686 00100462 84ca c.mv x9,x18 x0:0x00000000 x18:0x00000000 x9=0x00000000
```

## Steps to reproduce the issue

First I modified the config file and added a new config:
```
irq_test:
RV32E : 0
RV32M : "ibex_pkg::RV32MFast"
RV32B : "ibex_pkg::RV32BNone"
RegFile : "ibex_pkg::RegFileFF"
BranchTargetALU : 0
WritebackStage : 1
ICache : 0
ICacheECC : 0
ICacheScramble : 0
BranchPredictor : 1
DbgTriggerEn : 0
SecureIbex : 0
PMPEnable : 0
PMPGranularity : 0
PMPNumRegions : 4
MHPMCounterNum : 0
MHPMCounterWidth : 40
```

I executed the following sequence:
```
make -C examples/sw/simple_system/hello_test
fusesoc --cores-root=. run --target=sim --setup --build lowrisc:ibex:ibex_simple_system $(util/ibex_config.py irq_test fusesoc_opts)
./build/lowrisc_ibex_ibex_simple_system_0/sim-verilator/Vibex_simple_system -t --meminit=ram,examples/sw/simple_system/hello_test/hello_test.vmem
```

Then I observed the logfile `trace_core_00000000.log`

## My Environment

**EDA tool and version:**

Verilator 5.020 2024-01-01 rev v5.020

**Operating system:**

Ubuntu Linux 22.04

**Version of the Ibex source code:**

eea2bf0c1c62bbd676edf69cc60a56041d53b669

Reproduce the issue with the irq_test configuration and the hello_test program using the listed FuseSoC and Verilator commands. Start by tracing instr_skid_en around mret and the branch-prediction pipeline, then compare trace_core_00000000.log and the waveform with the expected trace. Done means mret does not cause the unintended consecutive instruction to retire.

Written by the indexing model from the issue text.