Smoke test some benchmarks in CI

[psfinaki]

This revives and builds on the smoke tests for benchmarks introduced by @safesparrow here. It doesn't check anything new in FCS, it just verifies that the benchmarks themselves don't explode.

A few notes:

• I don't want to bring ALL the benchmark projects to ALL the solutions, hence I keep the dotnet build FSharp.Benchmarks.sln to see that everything compiles and then do build.cmd so that we can execute FCS bench smoke tests. This is not a big waste of time
• Since some benchmarks are very long even for single execution - and we don't want this job to be the longest - I classify benchmarks into short and long categories and run only short ones (that's the majority though)
• I'd rather just have long category and run everything else, but this doesn't seem to be possible yet (and filtering by name would be too much hardcoding)
• The fsharp category is removed since it wasn't universal and wasn't used
• The script itself is renamed, moved and improved (since the BDN CLI is improved, e.g. job Dry supersedes hand-specifying all the job parameters)
• We also stop on the first broken benchmark

Running this immediately detected a broken benchmark (assuming Giraffe presence on the machine) so it's disabled.

The smoke testing now takes about 18 minutes, the whole job around 35 minutes. So it's not the longest - and we don't want it to be, hence if needed we can mark more benchmarks as "slow" and not smoke test them.

closes #16407
closes #16408

[github-actions]

✅ No release notes required

[vzarytovskii]

We shouldn't be running benchmarks in CI, since it's pointless and will be only burning cpu cycles for nothing.
Building them is enough to make sure they account for api changes.
Running won't add any useful info to CI.

[psfinaki]

We shouldn't be running benchmarks in CI, since it's pointless and will be only burning cpu cycles for nothing. Building them is enough to make sure they account for api changes. Running won't add any useful info to CI.

Discussed offline - this just checks that the benchmark tests themselves are sane.

We can give this a try:

• if our CI becomes faster and the smoke tests start taking the longest time (not the case now) - we can mark more benchmarks as "slow" and not run them at all
• if this somehow proves to be flaky, we can remove the script execution from CI, keeping only the build

nope