Performance of Renode/Verilator cosim

We should collect some statistics on Renode/Verilator cosimulation to check whether it is close to what would be expected.

* If the CFU was much "smaller" than the CPU, then we would expect Verilator simulation of just the CFU to require much less host time per simulated cycle than for CPU-only or CPU+CFU (PLATFORM=sim) Verilator simulation. However, in some cases such as `hps_accel`, the CFU is larger than the CPU, so we wouldn't expect much speedup (less than a factor of 2).
* I say 'smaller' in quotes since we are simulating the pre-implementation Verilog, so the work of simulating a particular design might *not* be proportional to the implementation LUT count.

* To get a handle on this, can we measure:
* Host time per simulation cycle for `proj_template` Verilated CFU (using cosim)
* Host time per simulation cycle for `hps_accel` Verilated CFU (using cosim)
* Host time per simulation cycle for `proj_template` CPU+CFU (full SoC simulation using PLATFORM=sim)
* Host time per simulation cycle for `hps_accel` CPU+CFU (full SoC simulation using PLATFORM=sim)

* Also, if the CFU is active only a small percentage of overall execution cycles, then we were expect the Renode/Verilator cosim to be much faster than full-SoC Verilator sim. But if the CFU is active the majority of the cycles, then we wouldn't expect much speedup due to this factor.

Can we print out the total number of cycles that Verilator simulates in Renode/Verilator cosim? Then this can be directly compared to actual execution on the board to get the total execution cycle count. This will give us an idea of the fraction of original execution cycles that the CFU needs to be simulated.

Finally, is the Verilator-generated C++ always generated so that it's capable of dumping waveforms? We should see how much faster simulation is if we disable waveform generation in the generated code.

FYI @alanvgreen