Simplify ownership of the list of comms

[lionel-]

Progress towards #689 and #691
Follow-up to #1161 (see console_comm.rs changes)

See #1075 for context: we're moving comms out of their own threads to run on the R thread, to simplify the concurrency structure of Ark and remove the risk of concurrent R evaluations which are UB (although these are now also tackled under a different angle, see #1222).

In #1161 I made progress towards phasing out unsafe mutation on Console state (see #1145) by using interior mutability in Console methods. To manage comm state in particular, I went for a take/move approach that removes a comm from the map of comms owned by the Console, and passes the moved comm by value to its handlers. This allowed data explorer comm handlers to manipulate the comm map and insert new explorer comms (when an inline explorer gets promoted to a full explorer).

Moving the comm was awkward with the UI comm though, which needed to be pinned down because its handlers might cause Console events that themselves require the UI comm (e.g. to send a message to the frontend). For this reason the UI comm used a different dispatch strategy with a shared borrow, that required ad hoc infrastructure.

The Help comm is also accessible from Console methods and is going to need a similar setup, so I thought I'd go ahead and try to simplify this:

• All comms now live in the map, including the UI comm. But they are now wrapped in an Rc.

• The dispatcher now holds an Rc clone of the comm rather than an exclusively owned value. The comm stays in the Console-owned map during dispatch, which is how they remain accessible for reentrancy while a handler is running. Thanks to the Rc wrapping and cloning, the comm map remains fully owned by the Console during dispatch and can be manipulated while a handler is running, allowing data explorers to clone/promote themselves.

  Note that the handler's &mut comes from interior mutability of the comm handler inside the ConsoleComm. So the one invariant we need to guarantee is that we never dispatch a comm's handler reentrantly.

• The UI comm still gets some ad hoc handling because of its "pinned" nature (there can only be one UI comm at any time, so opening a new one drops the old comm if any).