Advantage of PNPM is speed and storage size on disk: if you have
multiple projects using the same NPM package, NPM will store multiple
copies, but PNPM will store only one copy and share it between projects.

Most recent version of PNPM also requires Node version 18 or later, so
we'll bump any Node 16 references to most recent Node (22.2.0).

Also lets us remove the rebuild of node-sass, which was needed for devs
running a different architecture on their dev machines than the
architecture the Docker containers are built for (e.g. devs running Macs
with ARM chips, when the Docker containers we build are for x64).

Version 2 of date-fns had some assumptions built into the package about
the layout of node_modules that aren't true when pnpm is managing it.
Version 3 of date-fns fixed those assumptions.

By specifying `target: development` in docekr-compose.yml, we get the
same effect as specifying `docker build --target=development`: with
buildx, unused build stages (e.g., prod stages) are skipped.

…dows

One case switched to pnpm dlx instead of pnpm exec because there's no
package.json or node_modules in the test/e2e folder so pnpm exec would
fail, but pnpm dlx will run the tool globally regardless of location.

Can't use `pnpm exec` here either since it's being run in a step where
`pnpm i` has *not* happened, so there's no prettier binary to run.