Make lxtal clock source explicit

[dcz-self]

This makes explicit a blocking loop when setting up the LXTAL for the RTC. It's a precondition before adding an async version of the same wait.

The concept operates under the assumption that the LXTAL can be enabled and will never be disabled again.
Which ignores some corner cases, but addressing the clock source changing again would complicate the effort a lot.
Meanwhile,

• this is a good assumption for probably 90% of cases,
• it unblocks async version
• it shows future contributors that clock sources should eventually be modelled.

[Disasm]

This is better than nothing, but overall is not a good abstraction since it doesn't consume RCU, so anyone can call enable_block (enable_blocking maybe?), obtain the handle and then disable LXTAL, effectively invalidating the handle.

It might be a better idea to optionally return the handle from the clock setup code if LXTAL configuration was requested.

Please disregard, I was confused by Rcu != RCU

[dcz-self]

Unless I missed something, the crate user can't disable LXTAL because there's no safe public API for it.
There's Rcu::regs, but it's only pub(crate). The one way I know is for the user to get a reference to the RCU directly, but that's unsafe { &*pac::RCU::ptr() }, so I'm fine if the user makes a mess this way.
Or did I miss something?

About "_block" vs "_blocking", I did think about it, and I thought that "start_block" is easier to type, while still being grammatically clear. That's kind of similar to "verb_async" which I want to add alongside at some point.
I'm open to changing it if you still think that's a bad idea.