feat!: use `URLPattern` for request matching

[kettanaito]

[!WARNING] As much as I hate this, this is a breaking change. Some of your existing handlers may start matching differently if they contain one of the dropped features (path params merging or trailing slashes). Even if this is a change for the better, this should land in v3.0.

• Closes #1921
• Fixes #2204

This also significantly improves the test coverage for path matching in MSW.

This change does not intend to support URLPattern as the input. For now, we will use it as internal mechanism (thus a polyfill version). Once the API gains global browser support, we may consider shipping an input support.

Changes to document

• Multiple named groups are not supported: /:a/foo/:a. Not a thing in the HTTP spec. They are supported by path-to-regexp but URLPattern decided not to implement them and stick closer to the spec.
• Trailing slashes matter now. A /foo handler will not match a /foo/ request, and vice versa. I think MSW should respect that URLPattern behavior too to bring wider adoption of the API and be spec-compliant.

Roadmap

• [x] /foo/:a/bar/:a syntax throws in URLPattern. https://github.com/whatwg/urlpattern/issues/226. Doesn't throw in path-to-regexp and current MSW. Don't want to make a breaking change out of this.
  • Dropping this promise.
• [x] Support encoding since URLPattern doesn't.
  • Tests introduced in #980 are passing as-is.

[kettanaito]

This failing test:

 FAIL  src/core/utils/matching/matchRequestUrl.test.ts > merges multiple same-named groups into an array of values
TypeError: Failed to construct 'URLPattern': invalid pathname pattern '/user/:segment/bar/:segment'.
 ❯ new me node_modules/.pnpm/urlpattern-polyfill@9.0.0/node_modules/urlpattern-polyfill/dist/urlpattern.js:1:14389
 ❯ Module.matchRequestUrl src/core/utils/matching/matchRequestUrl.ts:96:19

Is caused by https://github.com/whatwg/urlpattern/issues/226.