Stop transpiling some builds to ES5

This is built on top of #1425 itself built on top of #1420, which
removes most dependencies to webpack (besides tests, that we'll need to
also change anyway considering the fact that `karma-webpack` has an old
reported issue on macOS with our build).

We planned to release in our future 4.1.0 an ES5 version of our worker
file and as a lesser feature an ES5 "legacy" build (the one linked to release
notes - not the one published on npm).

Providing an ES5 version of our worker file was especially added to
support the `MULTI_THREAD` feature on PlayStation 4 devices.

However I sadly propose here that we roll back that attempt of support
(just of the `MULTI_THREAD` feature, the PlayStation 4 stay officially
supported and tested).

---

After multiple attempts (myself and then @Florent-Bouisset), we realized
the complexities and costs of maintaining a supplementary ES5 version of
builds.

We initially tried to switch from a webpack+babel mix to swc on a bundle
already produced by esbuild.
The global idea was to simplify our bundling process by designing an
architecturally simple and low-maintainance process made of a separate
bundling step then transpiling step on the bundling result.

But we realized that this philosophy doesn't seem to be compatible to
those tools. When combined with the fact that their documentation is
often either lacking or too complex, than some of our questionning to
maintainers led to poor answers and that the JS tooling ecosystem appears
to be still changing very fast, I'm not sure that I want to guarantee
support of ES5 for our hopefully long-lived v4 right now.

doc/api/Miscellaneous/MultiThreading.md

@@ -383,29 +383,13 @@ if (currentModeInfo === null) {
 
 ## Note about ES5 Environment
 
-By default, the Worker file will use es2017 features which should be compatible to a
-majority of devices.
+The Worker file will use es2017 features which should be compatible to a majority of
+devices.
 
-However, some older devices might not be compatible with it yet still compatible to the
-WebWorker API (and thus the `MULTI_THREAD` feature), yet not with ES2017. For those
-platforms, the RxPlayer also provide an ES5 variant of the Worker file:
+However, some older devices might not be compatible with ES2017 yet still compatible to
+the WebWorker API (and thus could theoretically be compatible with the `MULTI_THREAD`
+feature).
 
-- The easiest way is to just import in your application its "embedded" version, exported
-  through the `"rx-player/experimental/features/embeds"` path:
-
-  ```js
-  import { EMBEDDED_WORKER_ES5 } from "rx-player/experimental/features/embeds";
-  ```
-
-  This allows to bypass the need to store and serve separately that file.
-
-  If you would prefer more control and a smaller bundle size, you may instead consider the
-  other following ways to it as a separate file.
-
-- With every release note published on GitHub as `worker.es5.js` (you should only use the
-  file linked to the RxPlayer's version you're using),
-
-- It is also available as `dist/worker.es5.js` from the root directory of the project
-  published on npm. As such, it might already be found in your project's directory, for
-  example in the `node_modules` directory (most probably in `node_modules/rx-player/dist/`
-  depending on your project).
+If you need to provide support for the `MULTI_THREAD` feature on those platforms, we
+recommend that you use a transpiler tool on that worker file to make it compatible to ES5.
+Examples of transpiler tools are [babel](https://babeljs.io/) and [swc](https://swc.rs/).