Add IDE messaging support to extensions API. Close #1406

[brollb]

This adds a pair of methods to the NetsBlox extensions for sending and receiving IDE messages. Messages are addressed using client IDs (as all IDE messages) and are passed to the same extension that originated the message to avoid message naming collisions and trivial compatibility issues.

@dragazo, @gsteinLTU - How's this look? Any questions/comments/suggestions?

[gsteinLTU]

I think there's a bit of confusion in what we were looking for. We were talking about messages being sent from a non-browser NetsBlox (i.e. the VM) to browser clients. The debugger extension Devin was going to make to display the VM errors would run as an extension, but it would need to receive messages from the VM running elsewhere, which can't run extensions.

This does look useful though, it might actually be helpful for the RoboScape Online extension since I could send a message to all collaborating clients prompting if they would like to join a session after someone creates one.

[gsteinLTU]

Or is there a corresponding PR for cloud I didn't see? NetsBlox/cloud#99 is sort of related in concept.

[brollb]

Yeah, this is only half of what is needed for the VM use-case. I still need to update the existing REST endpoint for message sending from the services server to be able to support messaging on behalf of an authenticated user (rather than just as an authorized services host - basically a read-only super user).

[dragazo]

So it looks like currently this doesn't let extensions name the message types (just uses the extension name itself)? That should be fine unless we wanted 2+ extensions that support listening to the same type of incoming messages (like different styles of debuggers that all receive the same raw input). That would be nice so the VM can always just generate messages of a single constant name and any extensions that want to receive it can just register a handler for it. I was imagining something like menu defs in extensions:

ideMessageHandlers() {
    return {
        'vm-error': function (data) { ... },
        'something else': function (data) { ... },
        'whatever': function (data) { ... },
    };
}

And if its handler is a function (rather than an arrow function), this would be the extension.

[brollb]

Yeah, we can certainly do something like that. I had just kept it simple assuming that most extensions wouldn't have too many different message types. (They can always implement a convention like checking the type field and passing to different handlers.) I don't have a strong opinion and am happy to change it either way.

[brollb]

@gsteinLTU - Just wrapped up the PR on the cloud side: NetsBlox/cloud#106