Deal with some npm false positives

See https://github.com/facebook/create-react-app/issues/11174
And https://overreacted.io/npm-audit-broken-by-design/

Eventually the context of use matters a lot.

> ### `npm audit` is broken for front-end tooling by design
>
> Bad news, but it's true. See [here](https://overreacted.io/npm-audit-broken-by-design/) for a longer explanation.
> ### If you think you found a real vulnerability in `react-scripts`
>
> If you **know** that it affects CRA users because you **understand** what the vulnerability is, report it [here](https://github.com/facebook/create-react-app/blob/master/SECURITY.md) as soon as possible.
>
> If you're **not sure** but your CI is failing or you're worried about what `npm audit` tells you, keep reading.
>
> **Do not** file new issues based on `npm audit` if you don't 100% understand the problem. They will be closed (see why below). If you really need to discuss it, reply in this thread instead.
> ### `npm audit` says there's a warning about vulnerabilities in my project
>
> Open `package.json`. You will find this:
>
> ```js
> "dependencies": {
> "react": "^17.0.2",
> "react-dom": "^17.0.2",
> "react-scripts": "4.0.3"
> }
> ```
>
> Take `react-scripts` and **move it to `devDependencies`** (if you don't have it, create it):
>
> ```js
> "dependencies": {
> "react": "^17.0.2",
> "react-dom": "^17.0.2"
> },
> "devDependencies": {
> "react-scripts": "4.0.3"
> },
> ```
>
> Then, **ensure you run `npm audit --production` rather than `npm audit.`**
>
> This will fix your warnings.
> ### But isn't this just ignoring the problem?
>
> No.
>
> Create React App is a **build tool**. In other words, it doesn't produce a running Node application. It runs at the build time during development, and produces static assets.
>
> However, `npm audit` is designed for **Node apps** so it flags issues that can occur when you run actual Node code in production. That is categorically **not** how Create React App works.
>
> This means that **the overwhelming amount of "vulnerability" reports we receive for transitive dependencies are false positives**. Despite [literally a hundred issues](https://github.com/facebook/create-react-app/issues?q=is%3Aissue+%22npm+audit%22+is%3Aclosed) with thousands of comments about `npm audit` warnings in `react-scripts`, throughout the years **not a single one of them** (to the best of our knowledge) has ever been a real vulnerability for CRA users.
>
> This is a huge waste of everyone's time. Mostly of yours, but of ours too.
> ### But I still see these warnings when creating a new project or running `npm install`
>
> Yes, unfortunately that's how `npm` works since v6. You can [bring it up with npm](https://github.com/npm/cli/issues). If enough people complain, maybe they'll rethink this decision. It is unfortunately actively hostile to build tooling.
>
> Note that you can run `npm install --no-audit` to suppress them.
> ### I know the transitive dependency has a fix, how can I try it?
>
> If you already know that `some-library@x.y.z` has the fix that you need, but `react-scripts` hasn't yet updated to it, you can try your luck using that version forcefully. With Yarn, you can do it using [resolutions](https://classic.yarnpkg.com/en/docs/selective-version-resolutions/). With npm, you might need to wait for [overrides](https://github.com/npm/rfcs/blob/latest/accepted/0036-overrides.md) or [npm audit fix overrides integration](https://github.com/npm/rfcs/blob/latest/accepted/0037-audit-overrides.md) to land first (it's not implemented yet). You can also try [npm-force-resolutions](https://www.npmjs.com/package/npm-force-resolutions).
> ### But can't a build tool have vulnerabilities, too?
>
> Yes, in principle.
>
> The few times there was an _actual_ vulnerability, it was reported separately, and we released patches as soon as it was possible. You can always report real vulnerabilities [here](https://github.com/facebook/create-react-app/blob/master/SECURITY.md), but please do this if you _understand_ the difference between a real vulnerability and a false positive. For example, a "Regex DDOS attack" can never be a real vulnerability for a development-time tool. If you're not sure, you're welcome to ask in this thread, but please keep it brief and to the point so that the thread doesn't become unreadable.
>
> Really, the worst problem is that _when_ there is a real attack poisoning the build toolchain, we won't know about it because it will be buried underneath the 99.9% of false positives.