Fix: Properly handle surface close event and operations.

[Ph4ntomas]

This PR handle several things:

• On the rust API side, closing events wasn't properly received in surface event-loop.
• On both rust and lua, operations were flaky as they could be sent and handled server side while views were in flight. This is especially problematic if a widget is hidden and we want to show it then apply an operation, as there are no way to know when a view has been sent to the server.

FIX done:

• Add an explicit close event for all surface types, that is sent when the server-side discard the surface.
• Refactor lua side of thing to match rust implementation. This help with delaying the operations, as well as align both codebase. Both codebase now have a main-loop which dispatch all events (messages/widget/surface/operation).
• Explicitly handle the close-event by breaking from the surface event-loop.
• Operation are no longer sent asynchronously. They are pushed inside the event-loop and will trigger a view refresh. to ensure they act on the latest view. This is technically wasteful as operation sent during an update cycle will trigger a new view. This could be improved in the future if it become an issue, so operation created during an update cycle are sent after the view for this update cycle, but it hasn't caused any issues.

I've merged changes from #445 into this PR as it made reworking lua easier.

Fixes: #443
Supersedes: #445

---

Original description

problem: it's possible for operate() call to apply on a stale view if a view is pending, leading to some operation failing.

solution: There are two part of this fix:

1. Enforce ordering of update and operate message by using the message queue used by message
2. Delay sending operate calls to the server until after the view was sent.

Fixes: #443

[Ph4ntomas]

Okay this works as far as I can tell, but I need to check/implement the lua side

[Ph4ntomas]

I now wonder if I should push this server-side, so it doesn't requires client-side tricks

[Ph4ntomas]

I now wonder if I should push this server-side, so it doesn't requires client-side tricks

Okay, so I did explore that route a bit, but came upon the following issue:

• server side has no idea what's the client side is doing:
  When an update comes from the client-side only (i.e. config generated messages), the server is not aware of that until after the client-side is done with its update. We could request a view, but we have no way of knowing that will be handled before the update ends.
• While operation don't currently return anything, they do in iced and moving synchronization server-side would make it harder to deal with. The client side implementation only requires a callback that would be called with whatever the RPC call return.

On the other hand, fixing ordering in lua the same way it was done in rust only required yield-able stream/channels. Those can be built from cqueues's promise and/or conditional variables, as cqueues is coroutine-based (no two coroutine runs at the same time) I went with a simple "spsc"-ish channel.
The implementation is pretty bare (an unbounded channel) and the channel sender is shared amongst all event source, but we don't need to synchronize the calls anyway and I did not see the point in doing anything fancier that we'd have to maintain.

[Ph4ntomas]

Some notes:
It may be possible to reduce the amount of view request we send. I don't think it should go here.

The way I see it, two improvements could be done:

• Don't call the request view RPC if one was sent and the new tree hasn't yet been sent
• Pool client-side message together, and handle them when the server sends its (potentially empty) event list as a reply to the view request.

I'm not doing that here, as I don't really see any need for it at the moment.