decode: add conditional branch op outputs
cappuccino: add branch prediction

To avoid a critical path from the set flag logic in execute stage to the
branch resolving logic in decode stage, a stall on the condition
l.sfxx; l.b(n)f was introduced for cappuccino.
This however yields a serious performance hit, since nearly all l.b(n)f
instructions are emitted right after the l.sfxx instruction by the
compilers.
To avoid this performance hit, branch prediction is introduced by:
Predicting the flag value in decode stage and do the conditional branch
according to the predicted flag, then compare the predicted flag in
execute stage with the actual flag coming from control/mem stage (the
l.sfxx instruction has moved there by now).
If they do not match, fetch stage is stalled, the on-going fetch is
discarded and the corrected target of the conditional branch is fetched
instead.

The actual branch prediction logic is contained in a seperate module,
currently it employs a simple static backwards branches taken, forward
branches not taken strategy, but the idea behind having it in a seperate
module is that this will make it more easy to implement more advanced
branch prediction strategies and make it reusable for other pipeline
implementations than cappuccino.
cpu: make branch misprediction visible to monitor
dcache: remove autotemplate from tag and way ram instantiations

All of the signals are templated, so there is really no benefit of using
autotemplate/autoinst on thos
dcache: tidy up WRITE state logic
cappuccino/wb_mux: remove redundant check for lsu_valid_i
pronto: add cache made of flip-flops

Enable via the usual FEATURE_INSTRUCTIONCACHE parameter, but only the
OPTION_ICACHE_BLOCKWIDTH value has any effect (no. of words is
2^OPTION_ICACHE_BLOCKWIDTH).
prontoespresso/fetch: add verilator lint_off WIDTH around parameters
true_dpram_sclk: explicitly describe read-new-data on read-during-write

Some devices can not infer 'read old data' as memory blocks
(e.g. Cyclone V), so explicitly describe read new data to allow
inferance of memory blocks on such devices.

This change of behaviour should have no impact on the current users
of this module (IMMU), since writes are only performed on one of
the ports by spr accesses, and spr accesses never read and write
at the same time.
WIP: itlb hw reload