Add the CLINT peripheral for ESP32-C6 and ESP32-H2

[jessebraham]

Copied from the TRM, should hopefully be correct but would appreciate some additional review here.

[mchodzikiewicz]

having a quick look, this looks all fine, a thing I consider missing is that there's a notion of HART (and HART-ID) in RISC-V that is missing in this PAC.

it is being used for example by RTIC's CLINT backend to determine on which core scheduling is being done, even though in this case there's only one, RTIC's CLINT backend codegen macro requires variant of enum that implements this trait: https://docs.rs/riscv-peripheral/0.2.0/riscv_peripheral/aclint/trait.HartIdNumber.html

(see https://github.com/rtic-rs/rtic/blob/master/rtic-macros/src/codegen/bindings/riscv_slic.rs#L250)

also, here's how this is being done for mcu that rtic is using as an example for clint backend
https://github.com/greenlsi/e310x/blob/master/src/pac.rs#L10
https://github.com/greenlsi/e310x/blob/master/src/lib.rs#L167

I can see that for e310x some registers that are 64 bit here are mapped as high and low 32-bit ones but if I would've been asked for opinion, I like 64-bit ones better, so maybe that's something to raise in other PACs (and dependent code)

[jessebraham]

Thanks for taking a look!

I am planning to adopt the new RISC-V functionality provided by svd2rust, including defining harts, and have created #297 to track this. I will handle this in a separate PR. Thank you for the pointers here, though!

I will take one more look at these changes and compare them with the TRM with fresh eyes a bit later today, then probably just merge this. If we decide the 64-bit registers need to be split up at a later date we can always do so, but I'd prefer to have them combined like I have done here I think.