Consider migrating all event-handling classes to Web Workers from EventEmitter

[EzraBrooks]

A common problem users face with using roslibjs is their main thread getting locked up when serializing or deserializing large messages. In the past, roslibjs addressed this by optionally having Web Worker support. I removed that support because it had decayed to a point where it was unclear if it could possibly work.

Today, now that Web Worker support is ubiquitous, I think we should consider migrating away from EventEmitter and to Web Workers. Web Workers have a similar event-oriented programming paradigm, and would offload each individual Topic, Service, etc. to a separate worker thread to prevent any from blocking each other or the parent application that is using roslibjs.

[EzraBrooks]

probably overkill - more likely we should do the following:

• incrementally parse the JSON to get the field that determines which event it will be emitted on
• spin up a Web Worker for each unique event name
• do the JSON parse in that web worker each time an event comes through on that event name

[drewhoener]

@EzraBrooks I'd actually be interested in tackling this if you're open to it, even though it's not planned. It would give me some nice gains in my react apps where the main thread is already working pretty hard

[EzraBrooks]

The design in the initial issue, or in my comment?

[drewhoener]

The one in the comment above, spinning up the web workers dynamically for topics

[EzraBrooks]

Sure! #1078