feat: Use unversioned frontend asset paths

[billyvg]

This reverts commit 388edc8.

This builds on top of #25744 where we refactored our JS entry points to be lightweight and to use dynamic imports (via webpack) to load the rest of the JS application.

This PR will now remove the need for the backend to be updated in order to release a new frontend. This will allow us to have frontend-only deploys which should complete much faster than a full deploy. We accomplish this by removing the webpack manifest plugin introduced in #25234, where we previously were versioning b
y a release string in the asset path. These unversioned asset files will be served using a
[Cache-Control: no-cache](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache
-Control#cacheability) header which tells clients that they need to check against the origi
n server to see if the asset has changed, if it has not, they can use their cached copy. Th
ese unversioned files will end up changing quite frequently with every release, but they sh
ould be relatively small. They contain the webpack runtime that allows us to load the rest
of our application bundles, which are versioned by a hash of their contents. These versione
d chunks will have a long-term max-age for caching as the hash in the file name will serv
e to cache bust.

Note: this was reverted in #25994 as it broke p
roduction due to our CDN having cached an old asset due to a cache misconfiguration during
development. This was also not caught in staging because we needed to change the asset path
s for staging deploys to avoid clobbering production assets, and the staging path was not p
reviously cached.

Requires #26987