More CSR options

[lmbollen]

What (what did you do)
Enable all CSR options in Vexriscv.

Why (context, issues, etc.)
Previously when the CPU trapped, it would not populate the mepc register (Machine Exception Program Counter) which indicates at which instruction the exception was thrown. We can trigger on such events and read out these registers as can be seen in this example https://github.com/bittide/bittide-hardware/blob/main/firmware-binaries/examples/smoltcp_client/src/main.rs#L195-L207 (copied for convenience):

#[export_name = "ExceptionHandler"]
fn exception_handler(_trap_frame: &riscv_rt::TrapFrame) -> ! {
    let mut uart = INSTANCES.uart;
    riscv::interrupt::free(|| {
        uwriteln!(uart, "... caught an exception. Looping forever now.\n").unwrap();
        info!("mcause: {:?}\n", mcause::read());
        info!("mepc: {:?}\n", mepc::read());
        info!("mtval: {:?}\n", mtval::read());
    });
    loop {
        continue;
    }
}

Without this change, both mepc and mtval are 0, so we get:

 Wait for "[MU] Demo complete.", got: [MU] INFO | 0:0:32.385 | mcause: Mcause { bits: 5 }
Wait for "[MU] Demo complete.", got: [MU] INFO | 0:0:32.385 | mepc: 0
Wait for "[MU] Demo complete.", got: [MU] INFO | 0:0:32.386 | mtval: 0

After this change, we get for example:

Wait for "[MU] Demo complete.", got: [MU] INFO | 0:1:27.697 | mcause: Mcause { bits: 5 }
Wait for "[MU] Demo complete.", got: [MU] INFO | 0:1:27.698 | mepc: 2147520478
Wait for "[MU] Demo complete.", got: [MU] INFO | 0:1:27.698 | mtval: 2147811340

Which tells us where the CPU trapped and gives some context dependent info (in this case which address it tried to access).

Dear reviewer (anything you'd like the reviewer to pay close attention to?)
Are there any options we should not enable? It builds and runs fine.

[hiddemoll]

Lucas and I shortly discussed this change in the office. Going from the smallest configuration to all seems like a big change to me. We compared the synthesis reports and in terms of added logic it adds little.

This is not really my cup of tea, so I'd like @hydrolarus to look at this PR as well.