Guarantee that there are events associated with interfaces that inherit from `EventTarget`

[tidoust]

Via #1212 (comment).

We already use the fact that an interface inherits from EventTarget to find target interfaces for events when we extract them from the specs, but we don't have test in place that checks that:

1. All interfaces that inherit from EventTarget are targeted by at least one event (for example: there should be events that target CloseWatcher)
2. We have a suitably named event for all EventHandler attributes in such interfaces (for example: there should a cancel event that targets CloseWatcher because it has an oncancel attribute.

Depending on what research reveals, this test could be turned into a guarantee for the @webref/events package. There may be exceptions to the rule though (such as new interfaces for which the draft spec does not yet correctly define associated events)

[tidoust]

I've been looking into adding a check to Strudy's study-webidl. A couple of things make that slightly painful:

• We want the more specific target when possible when the event handler is defined on a common ancestor interface. Logic needs to follow inheritance chains as a result. That's ok, it's relatively easy to check that in practice.
• An interface may end up with an EventHandler attribute even though the related event does not fire at it, when the interfaces are part of a bubbling tree, and when the event bubbles. That's more painful to test: either we start from the consolidated events.json file or we need to expose Reffy's bubbling logic somehow. In practice, we're only talking about a couple of events in IndexedDB, most other bubbling events get simply captured through inheritance (in HTML, event handlers are defined on HTMLElement).

I'll try to prepare something relatively clean for integration in Strudy. In the meantime, the analysis reveals that we could almost guarantee that "all event handlers get targeted by a suitable event", but for the following cases:

• No orientationchange event found for HTMLBodyElement.onorientationchange (compat).
  This one is interesting because we're the ones who remove the HTMLBodyElement target. The IDL definition of HTMLBodyElement does have the event handler though. I guess that's going to remain an exception to the rule? (That is, unless you're on iOS Safari, the event handler will indeed never be called).
• No error event found for RTCIceTransport.onerror (webrtc-ice).
  Also interesting because there is an event but its name is icecandidateerror. That seems to be the only case where the name of the event handler attribute is not the expected one. Any reason why the event handler was not named onicecandidateerror?

[Edit: problems reported and fixed] This also reveals 4 other problems in WebXR Layers, where the redraw event is defined to target the root XRLayer interface, whereas the event handlers are defined on specific interfaces that inherit from XRLayer. I'll report the errors:

• No redraw event found for XRQuadLayer.onredraw (webxrlayers-1)
• No redraw event found for XRCylinderLayer.onredraw (webxrlayers-1)
• No redraw event found for XREquirectLayer.onredraw (webxrlayers-1)
• No redraw event found for XRCubeLayer.onredraw (webxrlayers-1)

While digging into data, I also bumped into the definition of XHR events, which are currently defined with a data-dfn-for="XMLHttpRequest" attribute, while they also fire on XMLHttpRequestUpload. The attribute should rather be data-dfn-for="XMLHttpRequestEventTarget".