Part of: #18838

This pull request seeks to enable type checking for the @wordpress/priority-queue package.

Implementation Notes:

A few details here worth noting, as it can impact future types efforts:

• Dealing with experimental DOM features (requestIdleCallback) or otherwise-unsupported window globals. In this case, it's fortunate there's a DefinitelyTyped package for @types/requestidlecallback. In other circumstances, we may need to consider how this be handled (e.g. allowable .d.ts files for augmenting the global scope, which might be the only option).
• Dealing with known non-nullables. See the required revisions to typecast the result of waitingList.shift(). This is apparently a common problem, where TypeScript-proper affords some of its own options (the non-null assertion operator). These inline type-castings may be a suitable alternative, but they're reasonably clumsy to work with.
• Type intersections cause an ESLint warning for valid-jsdoc. See also related issue at Typescript types should parse correctly jsdoctypeparser/jsdoctypeparser#50 . To me, it seems like something where a future version of jsdoctypeparser (eslint-plugin-jsdoc) will have better support for these syntaxes, but we may need to be willing to allow for the warnings in the interim. It could be an open question as to whether we want to include eslint-disable inline configurations to avoid the warnings.
• A few potential convention discussions emerge here:
  • Can we be okay for a condensed single-line @type tag when documenting the type of an inline variable (e.g. /** @type {WPPriorityQueueContext[]} */)? I worry that if we force these JSDoc to occupy at least three lines each, there might be some reluctance/resistance due to its verbosity.
  • Can we be okay to omit descriptions for some custom types? See affected WPPriorityQueueAdd, etc. I think this is something where we'll want to strike a balance of pragmatism on what's reasonable to document. An exhaustive set of descriptions here might be difficult to achieve, and provide minimal value vs. an adequate description on the parameters where the types are referenced. To me, it can also be one of those things where we approach it from a mindset of iterative improvement over time, and avoid added barriers to introducing types.

Testing Instructions:

Verify types checking passes:

npm run lint:types

There are no unit tests for @wordpress/priority-queue, so it might be worth doing some brief user-testing of the affected usage (useSelect uses the priority queue).