Activate the selector check for the `autoprint` integration test as soon as possible

…oon as possible

The Windows bot is usually slower than the Linux bot, and therefore
text layer rendering is as well. However, the `autoprint` test awaited
text layer rendering to complete before activating the selector check,
which makes it timing-sensitive and causes it to never resolve because
the page is already printed (and the printed page div removed) by then.

This commit should fix the issue by activating the selector check as
soon as possible, namely as soon as the viewer appears, which should
ensure we're always registering the selector check in time because we're
doing it even before rendering is starting.

[api-minor] Stop polyfilling `structuredClone` in legacy builds

Comparing the currently supported browsers/environments, see [the FAQ](https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support) and the [MDN compatibility data](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone#browser_compatibility), the `structuredClone` polyfill is *only* needed in Google Chrome versions < 98. Because of some limitations in the core-js polyfill we're currently forced to special-case the `transfer` handling to prevent bugs, and it'd be nice to avoid that.

Note that `structuredClone`, with transfers, is only used in two spots:
 - The `LoopbackPort` class, which is only used with fake workers. Given that fake workers should *never* be used in browsers, breaking that edge-case in older Google Chrome versions seem fine.
 - The `AnnotationStorage` class, when Stamp-annotations have been added to the document. Given that Google Chrome isn't the main focus of development, breaking *part* of the editing-functionality in older Google Chrome versions should hopefully be acceptable.

Output `pdf.scripting.js` as a JavaScript module (PR 17055 follow-up)

To avoid problems with `export` statements in the QuickJS Javascript Engine, we can work-around that by *explicitly* exposing `pdfjsScripting` globally instead.

[api-major] Output JavaScript modules in the builds (issue 10317)

Remove unnecessary alpha-value from CSS `rgb` colors

At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]

In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.

Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.

One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]

---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility

[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.

[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.

[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.

The user should *always* provide a correct `GlobalWorkerOptions.workerSrc` value when using the PDF.js library in browser environments. Note that the fallback:
 - Has been deprecated ever since PR 11418, first released in version `2.4.456` over three years ago.
 - Was always a best-effort solution, with no guarantees that it'd actually work correctly.
 - With upcoming changes, w.r.t. outputting JavaScript modules, it'd now be more diffiult to determine the correct value.

The minified default viewer has never been distributed in either official releases or through pdfjs-dist, which means that it's most likely unused, and it's has never been tested nor actively maintained.

[Editor] Add the possibility to create a new editor in using the keyboard (bug 1853424)

Setting the alpha-value explicitly to `1` in `rgb` colors is unnecessary, since that's the default value, and this way we ever so slightly reduce the size of our CSS files.
Unfortunately I've not found a Stylelint rule to enforce this automatically, and the patch was generated using search and replace.

…oard (bug 1853424)

When an editing button is disabled, focused and the user press Enter (or space), an
editor is automatically added at the center of the current page.
Next creations can be done in using the same keys within the focused page.

Make the toolbar buttons usable with keyboard when Page Fit is used

Enable some Stylelint color-related rules to slightly reduce file sizes

 - Use a consistent format for all alpha-values (this rule didn't require any code changes); see https://stylelint.io/user-guide/rules/alpha-value-notation
 - Use modern and slightly shorter color notation, since [according to MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/rgb#browser_compatibility) that should be supported "everywhere" nowadays; see https://stylelint.io/user-guide/rules/color-function-notation/
 - Use "short" hexadecimal colors whenever possible; see https://stylelint.io/user-guide/rules/color-hex-length/
 - Help avoid adding broken hexadecimal colors (this rule didn't require any code changes); see https://stylelint.io/user-guide/rules/color-no-invalid-hex/

Add a HTML containter for locked FreeText annotations in order to be able to display a popup (follow-up of #17070)

…able to display a popup (follow-up iof #17070)

Update the noHTML flag to take into account the hasOwnCanvas one (fixes #17069)

[Editor] Add role=spinbutton to resizers when they're used with the keyboard

…eyboard

#17069)

When an element has the hasOwnCanvas flag we must have an HTML container to attach
the canvas where the element will be rendered.
So the noHTML flag must take this information into account:
 - in some cases the noHTML flag is resetted depending on the hasOwnCanvas value;
 - in some others, the hasOwnCanvas flag is set depending on the value of noHTML.

[Editor] Support resizing editors with the keyboard (bug 1854340)

Add support for "GoToE" actions with destinations (issue 17056)

This shouldn't be very common in practice, since "GoToE" actions themselves seem quite uncommon; see PR 15537.

Bump library version to `4.0`

Compute correctly the bounding box of a transformed rectangle (fixes #17065)

…17065)

Ensure that readonly TextWidget-annotations are rendered when forms are disabled (issue 17064)

…re disabled (issue 17064)

To reduced the risk of regressing something else, given that the issue only applies to a (for the default viewer) non-default configuration, this patch is purposely limited to only TextWidget-annotations in the display layer.

[api-major] Remove the SVG back-end (PR 15173 follow-up)