Ark: Extend `IOPub` with a `PromptState` message type rather than using the UI comm

See https://github.com/posit-dev/amalthea/pull/383#discussion_r1631412986

Currently we send prompt updates to the frontend using a custom UI message called PromptState:
https://github.com/posit-dev/amalthea/blob/e7f8b98c5e4deebeb28120a584f7599e307ffbbd/crates/ark/src/interface.rs#L603

We do this because there isn't a good way in the Jupyter protocol for the backend to initiate a prompt configuration change, but that is fairly common in R (an interactive command can update the prompt global option, possibly in a dynamic way like Gabor's prompt R package).

With https://github.com/posit-dev/amalthea/pull/383, we lost the ability to immediately update the frontend prompt state after sourcing a user's .Rprofile, instead it is updated after the first execute_request comes through a little later (i.e. the first time code is run in the console). This is a little awkward.

Knowing that .Rprofile is a somewhat common place to put prompt updates, @lionel- and I thought that we could send over a UiFrontendEvent::PromptState message right after sourcing the .Rprofile, that would enable the frontend to update the prompt quickly. The problem is, the UI comm isn't typically connected yet! What is connected at that point is the IOPub socket, so we could send this message through there instead using an "extension" to the protocol in the form of a custom PromptState message.

We'd update both the R and Python side to use this rather than the UI comm, and update the frontend code accordingly. I'll label this as an R issue though, as it is mostly for R.

Start with crates/ark/src/interface.rs around the existing UI PromptState message, then trace the IOPub and UI comm paths described in the issue. Review how the R, Python, and frontend sides handle PromptState after sourcing .Rprofile. Done means prompt updates use the IOPub message and reach the frontend immediately.