Audio Clock Throttle

More a rough idea for a better Clock Throttle. This differs from standard Audio Throttle, which throttles based on whether the audio driver has eaten up audio samples. This generally works great, however, it fundamentally can't operate with speed increments/decrements, only fast forward/turbo. It also just has the flaw of being imprecise with its throttling, as audio drivers typically don't do better than just eating ~10 ms of samples at a time, and can potentially be much worse, in any case ultimately being very uneven with frame timings. Audio Clock Throttle would work as simply using the core's audio samples as a metric of timing info. Instead of just going with 1 frame = Vsync Den/Num time has passed, simply consider how many samples / 44100 has passed. This can have increments/decrements of time just like Clock Throttle. This also can be understood to just be like Sync To Audio operates with A/V writing, and similarly it wouldn't have pitch issues like standard Clock Throttle has.

Not sure how easy it would be to implement such, throttle class would need to know samples taken from the core in host sound handling (dunno, add callback to host sound manager which gives number of samples to throttle class?). Of course too, it would be nonfunctional if renderSound is false (although such cases presumably want unthrottling anyways?)

see also #3562

Start by reviewing the throttle class and host sound handling, especially how core audio samples are exposed, and compare the proposal with issue #3562. Done would mean determining whether sample-based timing can support speed increments and decrements without the pitch issues of standard Clock Throttle, while accounting for renderSound being disabled.