Add support for target prediction in JumpBranch unit

[xThaid]

This PR prepares the jump branch unit for JALR target prediction. To do so I did the following changes:

• move a big part of the JB unit logic from issue to accept method. The rationale is that JALR targets will be stored in memory, which will have one cycle delay. Thus, we can't tell if we mispredicted at the time of issue. I know that this most likely will affect our longest critical path, but the announcement needs to be cut somewhere in the middle anyway.
• I added stubs for the methods used to get the JALR target prediction
• The request method doesn't take any arguments right now and that's deliberate - we can't make target prediction now anyway.

[github-actions[bot]]

Benchmarks summary

Performance benchmarks

aha-mont64	crc32	minver	nettle-sha256	nsichneu	slre	statemate	ud
▼ 0.418 (-0.008)	0.513 (0.000)	▼ 0.337 (-0.013)	▼ 0.655 (-0.000)	▼ 0.355 (-0.009)	▼ 0.290 (-0.003)	▼ 0.327 (-0.002)	▼ 0.433 (-0.002)

You can view all the metrics here.

Synthesis benchmarks (basic)

Device utilisation: (ECP5)	LUTs used as DFF: (ECP5)	LUTs used as carry: (ECP5)	LUTs used as ram: (ECP5)	Max clock frequency (Fmax)
▼ 23284 (-801)	▲ 5888 (+120)	802 (0)	▲ 976 (+72)	▲ 50 (+3)

Synthesis benchmarks (full)

Device utilisation: (ECP5)	LUTs used as DFF: (ECP5)	LUTs used as carry: (ECP5)	LUTs used as ram: (ECP5)	Max clock frequency (Fmax)
▼ 28112 (-4299)	▲ 9141 (+120)	1976 (0)	▲ 1156 (+72)	▲ 42 (+1)

[xThaid]

Branches are now resolved one cycle later, so most likely we need to flush one more instruction during an exception. Thus performance dropped.