Direct communication link between user JS and JL for JSServe support

[fonsp]

Split off from #991. This PR is a subset of #991, only adding the simple JS-JL link, without WebIO support, and without AssetRegistry support.

We decided to work on supporting JSServe instead of WebIO because JSServe is being actively maintained and developed (SimonDanisch/Bonito.jl#118), while WebIO and its dependencies are not developed/maintained as much, and they are currently not compatible with HTTP 1.0, which is painful for the Julia ecosystem.

JSServe will also be easier to support, especially in Pluto's HTML Export, as it does not require hooking into the HTTP server. Instead, it uses data URIs, and maybe #1124 to transfer data.

This will add stable out-of-the-box support for WGLMakie!!

Thanks @dralletje for the initial work for this PR!

TODO:

• The API choice for the Julia side is still difficult. It would great to expose the Julia API via AbstractPlutoDingetjes, or perhaps a new package. It would help if we first finish:
  • Display.published_to_js JuliaPluto/AbstractPlutoDingetjes.jl#8 and
  • Display.@auto_id() for automatic script ID JuliaPluto/AbstractPlutoDingetjes.jl#7
• The API for the JS side also needs to be decided. We currently define a global Pluto object, but we could also pass it into the script directly, like we do for invalidation and currentScript.
• We need a basic end-to-end test added to our puppeteer tests.

[github-actions]

Try this Pull Request!

Open Julia and type:

julia> import Pkg
julia> Pkg.activate(temp=true)
julia> Pkg.add(url="https://github.com/fonsp/Pluto.jl", rev="js-jl-link-for-jsserve")
julia> using Pluto

[disberd]

@fonsp is there any way to help with this PR?
I think it would really enable a lot of cool functionality (look at all the internal refs to this PR) and it's a pity that is basically stale since quite a while

[fonsp]

Replaced by #2726