Add async API to TSC

[Eekle]

First punt at contributing peripheral code, I hope it's close to where it needs to be.

Based off what I read in rng.rs, on the advice of @kkoppul2

Some questions I have:

• What, if anything, should happen to the existing start_it and poll_for_acquisition methods
• Is it okay that this requires Irqs be linked up to use the TSC? Or should it be optional?

[kkoppul2]

I'm thinking we can have two constructors here, one with the interrupt, one without. Then users can choose how they want to use it. Make the irq an option.

[Eekle]

I'm thinking we can have two constructors here, one with the interrupt, one without. Then users can choose how they want to use it. Make the irq an option.

Would this be best achieved as an additional type parameter on the Tsc struct?

[kkoppul2]

Yeah we can add the interrupt handler as an option and then follow the paradigm of the peripheral mode (Async vs Blocking) and have a constructor for each implementation. The Async takes the interrupts, the blocking doesn't. Then maybe we can combine the non-interrupt start function with the polling function and move that to the Blocking impl and the start_it to the Async impl. Most of the bus implementations already follow the pattern for reference.

[Eekle]

@kkoppul2 Updated with async/blocking split.

I have just removed the _it functions altogether, since the async wait works with the normal start func. I hope that's not problematic?