Introduce a mirror event target

[NavidZ]

Introduce a mirror event target to have an EventPort property.

[NavidZ]

Tries to fix #6.

[NavidZ]

@smaug---- This patch needs a lot more work to do. At the very least we need to first address the targeting issue in html spec so I can better defined what happens to a mirror target when created. But let's first agree in the overall approach and whether you are also okay with not queueing all the events similar to an EventPort.

[Kaiido]

Why is it said that the Element interface is extended? Shouldn't it be the whole EventTarget one?
Some will certainly want to listen for Window's resize event, or other Interfaces that are not Elements, like MidiInput or alike.

Do we really want all the methods from EventTarget to be accessible on the "mirror"?
Due to its synchronous nature dispatchEvent seems quite complicated to implement.

[NavidZ]

@mustaqahmed FYI

Why is it said that the Element interface is extended? Shouldn't it be the whole EventTarget one?
Some will certainly want to listen for Window's resize event, or other Interfaces that are not Elements, like MidiInput or alike.

EventTarget is too generic and doesn't necessary belong to the DOM nodes that have some visual representation. But Element is just a start I'd say.

Do we really want all the methods from EventTarget to be accessible on the "mirror"?
Due to its synchronous nature dispatchEvent seems quite complicated to implement.

One of the ideas was to let the worker to dispatchEvent as well (although stating that the listeners on the main thread might async and there is no guarantee on that). But we can have synchronous running of the listeners at least on the worker side. Although I agree this is not explicitly mentioned here in this PR.

[Kaiido]

EventTarget is too generic

I'm only a web author, so I may very well miss a lot about how things work under the hood.
Still, if I try to put myself in an hypothetical implementer's shoes, having to implement this on the Element interface seems almost as complicated as having it on the whole EventTarget, isn't it?
I understand your intention as trying to provide a minimal API first and extend it later, with your current main use-case being UI-events.
But the Element interface is in itself a lot broader than just UI-events, just have a look at the events firing on MediaElements, and there are many others, and that is without even talking about untrusted synthetic events.
Maybe to achieve what you wanted, there should be an UIEventTarget pseudo-interface defined, so that only UIEvent instances are taken into account, but then, with my web author hat back on, I'd find it very confusing, and very complicated to remember which events exactly do belong to the UI-Events: resize? nope, focus or scroll? yes in FF but not in Chrome, etc.
I also think it would make the specs actually more complicated to only cherry pick some events, rather than to define a globally applicable solution directly, but I'm really not a spec author, so I'll let you judge on that matter.

(although stating that the listeners on the main thread might async and there is no guarantee on that)

Once again with my simple web-author hat, I wonder if such behavior wouldn't lead to some undefined or at least some very complicated to guess behavior / race conditions.
In my opinion, that might be a lot simpler to make it act only as an observer, and even limit the events received to be some kind of opaque events. This would still allow most use cases, without creating complex atomic operations.

---

FWIW, here is a little playground I'm working on, loosely based on this PR.