Update export structure, change bundler, move tests to ESM

[Acconut]

This PR started out as an attempt at changing how tus-js-client's package.json defines its exports (see #693). Instead of using only the main, module, and browser fields, it can now utilize the new exports syntax to allow bundlers and loaders to correctly resolve to CommonJS or ESM and their corresponding types. In addition, it paves the way to definition subpaths for environment-specific functionality, e.g. tus-js-client/node/NodeHttpStack.

Along the way, I switched the bundler for building tus-js-client and its tests from Browserify to Rollup because browserify does not support the new exports structure. Additionally, I changed the tests from CommonJS to ESM, because Rollup itself only supports ESM. In the end, it turned out that this change was not strictly necessary since we needed to install a plugin that makes Rollup consume CommonJS because some of tus-js-client's dependencies are not ESM-compatible yet.

To better supports loaders that don't understand the exports structure, tus-js-client also ships with fallbacks as explained in https://github.com/andrewbranch/example-subpath-exports-ts-compat/tree/main/examples/node_modules/package-json-redirects.

Finally, arethetypeswrong and publint are installed as additional linters to ensure

TODOs

• Add a web-only feature (e.g. a FetchHttpStack): Add HttpStack using Fetch API #751
• Make pre-release: https://www.npmjs.com/package/tus-js-client/v/5.0.0-pre1
• Test pre-release in different scenarios (node/browser, JS/TS, different bundlers)
• Make TypeScript emit sourcemaps, so rollup can consume the sourcemap and build from that. EDIT: Let's not do this because Rollup needs another plugin for consuming sourcemaps: Read existing source maps for imported modules rollup/rollup#4532

[Acconut]

Test pre-release in different scenarios (node/browser, JS/TS, different bundlers)

I did an extensive testing round using various setups and the pre-release v5.0.0-pre1 completed all of them. The tests included requiring the main package entry (tus-js-client), as well as a sub-path (e.g. tus-js-client/node/NodeHttpStack). In addition, I confirmed that it was not only able to load the packages, but can also complete a proper upload. If TypeScript was involved, I checked that TypeScript loaded the correct types and was able to spot type issues.

The tested scenarios were:

• For Node.js:
  • CommonJS module requiring tus-js-client
  • ES module importing tus-js-client
  • TypeScript, compiled to CommonJS, importing tus-js-client
  • TypeScript, compiled to ESM, importing tus-js-client
• For browsers:
  • ES module bundled by Webpack
  • ES module in TypeScript and bundled by Webpack
  • ES module bundled by Rollup
  • ES module bundled by Parcel
  • ES module bundled by esbuild
  • CommonJS script bundled by browserify

Finally, arethetypeswrong and publint now don't report any errors anymore.

All in all, I am quite confident that with these changes tus-js-client achieves wide support and is compatible with modern and legacy system.