`lightning-liquidity`: Consider ways to make event handling API more robust

[tnull]

Currently, LiquidityManager::next_event/LiquidityManager::next_event_async return the next event an repersist the event queue (post #4059), which puts the responsibility to safely handle any important events on the user.

While some events are only informational and are not even persisted, some are critical to be able to continue the flow after a restart, for example LSPS2ServiceEvent::OpenChannel.

Currently, there might be a race if the user isn't super careful about how they implement their node logic: if the service happens to shutdown/crash just after calling next_event but before actually opening the channel, the service might lose the OpenChannel event.

We should eventually consider ways how we can make this less error prone, for example

a) Mirror the lightning event handling approach where we force the user to handle the event inline before returning the event handler function.
b) Regenerate any critical events on restart, while ensuring users have ways to make all of them idempotent
c) Have users detect what channel opens are pending based on #4101