Introduce vite to transpile js/css assets for development and production + vitest for static file testing

[KevinMind]

Relates to: mozilla/addons#2000

Important

This PR contains #22955 which should be merged first

Description

• Introduce vite and vitest targeting only the preload.js and analytics.js scripts initially.
• add infrastructure to support building and serving vite files

Context

This PR introduces the "plumbing" needed for compiling assets with vite. It does not migrate all assets to using vite. We should split this up after landing this and we can move assets over to esm with vite.

Vite

Vite will now compile every file in ./static/js/*.js and ./static/cs/*.less into independent bundles. Those files can then be included in our django app via the helper method vite_asset.

For example:

{{ vite_asset('js/preload.js') }}
{{ vite_asset('css/common.less') }}

This will render roughly to this:

<script src="<vite_asset_url>" />
<link href="<vite_asset_url" />

In development mode, vite_asset_url will resolve to /static/bundle/<path> where path is the original path to the url.
Nginx routes /static/bundle/ to the vite dev server which will then return the asset compiled in real time. LESS will return CSS and JS will return transpiled js.

In production mode, vite will compile the assets and save them in ./site-static/assets/ and a manifest will be used to resolve the url to the file path. Nginx will mount this path and serve files directly. In production environments, like before we will serve files from a CDN.

Testing

Dev mode

Run the dev/prod version of the app and make sure that:

• assets are being served successfully
• no console errors or runtime errors in the modified javascript
• all functionality remains unregressed.

make up DOCKER_TARGET=development

Prod mode

make up DOCKER_TARGET=production

Automated tests

Run the following tests which are now using vitest instead of jest

• make test_setup
• make run_js_tests

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.