Closes #18259

Historically, we've had some frontend code to detect conditions which would lead to build failures, and we would require their correction before ever talking to the backend. In a dynamic parameters world there are now many more possible ways this could fail and validating all of that on the frontend would be a lot of duplication and have a lot of room for logic errors.

We have decided to simplify, and delegate all parameter validation to the backend. The only ways which can authoritatively validate parameters is to actually trigger a build or establish an evaluation loop over WebSocket. As such, instead of doing any upfront validation on the frontend, we should just queue up a build and see what happens. This has two primary outcomes...

1. The build is fine, which means we would've queued it up anyway after validation (if we were doing any frontend pre-validation)
2. The build fails and we get back validation errors. We detect this and redirect to the parameters settings page, where an evaluation WebSocket will be established and the user can update things as necessary. When they are done, they'll queue another build from here which should succeed.

Importantly, the build will fail during a validation step that is performed on the backend. It will not actually add a job to the job queue. It does not require the availability of a provisioner. The response time was always very fast when testing locally, and shouldn't be of concern.