feat: [#2375] add window.event legacy "current event" global during dispatch

[marciomazza]

Description

Resolves #2375

window.event is always undefined in happy-dom. Real browsers set it to the event
being dispatched for the duration of dispatchEvent(), then restore the previous value —
the HTML spec's "current event".
Libraries that still read it (e.g. React's getCurrentEventPriority()) hit a TypeError
without it.

const target = new EventTarget();
target.addEventListener("test", () => {
  window.event; // happy-dom: undefined — real browsers: the Event object
});
target.dispatchEvent(new Event("test"));

Fix: BrowserWindow gets an event field (default undefined, like idle browsers —
not null). EventTarget.dispatchEvent() saves the current window.event, sets it to
the event, and restores it in a finally so a throwing listener can't leave it stale.

Two spec deviations left on purpose: window.event is set once around the whole dispatch
rather than per listener invocation, and listeners in a shadow tree
(invocationTargetInShadowTree) are not excluded from seeing it.

Tests

Added 3 tests: window.event is the event during dispatch and undefined again after;
a nested dispatchEvent() restores the outer event on return; a throwing listener still
restores it. Full npm test passes (303 files / 7804 tests).

Before submitting the PR, please make sure you do the following:

• Read the contributing guidelines.
• It's really useful if your PR references an issue where it is discussed ahead of time.
• Please check Allow edits by maintainers to make review process faster. Note that this option is not available for repositories that are owned by Github organizations.

Tests

• Make sure to add tests for your changes. Run your test in a real browser to make sure that the test tests what a real browser would do (e.g. by running the code in the browser console).
  • Ran the repro in Chrome 152 — window.event matches the new tests (idle undefined, the event during dispatch, restored on nested-dispatch return, restored after a throw).
• Run the tests with npm test locally to make sure that all tests pass before submitting the PR.

Title

• The title of the pull request should be in the format of "type: [#issue] description". The type can be feat, fix, chore or BREAKING CHANGE. The issue is optional and can be omitted if the pull request does not relate to an issue.
• The title should be concise and descriptive. The title will be used when generating release notes. Make sure that the title is easily understood by users of the library.

AI

I used Claude Code to write this, over multiple iterations. I guided and reviewed
it myself at every step.