Don't use ChannelMultiplexer in RPCProtocol

[tsmaeder]

What it does

The use of a ChannelMultiplexer in RPCProtocol was causing the sending of request from the plugin host to be delayed until a sub-channel could be opened. This would lead to the reply for the request that caused the "callback" to the front end to be sent before the request from the plugin host.
This PR removes the channel multiplexer from the RPCProtocol and instead just sends the proxy id as an additional parameter.

Fixes #13960

Contributed on behalf of STMicroelectronics

How to test

Since this PR fixes a problem discovered in #13306, we'll need that on to be merged in order to test that the issue is actually fixed. What we can test right now, though, is that the change does not cause any trouble for the operation of plugins. This means using plugins and observing the logs, etc.

Follow-ups

The startup sequence for plugins hosts is still not entirely deterministic. Some of the ideas in #8437 would still be worth reviving in new PR, even though we don't run into any timing problems, currently.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[tsmaeder]

@msujew this one would be good to get merged soon to get the code exercised a bit before the next release. @tortmayr is on vacation until the next week.

[msujew]

Looks good to me. I can confirm that extension features still work as expected (tested with TypeScript & Jupyter). Less code is always better :)