clock_control: API should support asynchronous and synchronous variants of turning on clocks

[SebastianBoe]

Turning on a clock can take a long time, especially to wait for it to stabilize.

The clock_control driver API should have a runtime-configurable API for turning on a clock synchronously or asynchronously.

Currently it is only Kconfig-urable whether it is done synchronously or asynchronously.

Also, piggy-backing on this issue, (if asynchronous clock enable is to be supported) there should exist
a function, is_clock_running(), (where running implies 'stable' (According to spec.)).

#8803

[tbursztyka]

Looks like a legitimate API change.
However, about having "is_clock_running()", I would instead return "-EALREADY" on off/on calls, as long as the clock is already fully stable on respectively off/on states. Which means that, if - let's say - a on is called in a middle of an on-going on call, it would have to return -EBUSY. (same for off obviously).
This would save one pointer on driver API side, and make on/off behaviour very clear.

[SebastianBoe]

All right, (although not documented) this is the current behaviour of nrf's clock_control. So if there are technical reasons to not have an is_stable then that makes sense.

But a doc update would be nice ...