Add connection/stream count selections to the benchmarks/dashboard

I thinking a bit more about the YARP results compared to NGINX, in chatting with @sebastienros, crank is controlling the incomming rate based on a fixed number of connections, and then streams within those connections.
We get different results according to the number of connections that are thrown at us. Based on http/1.1 with a 1024 byte payload we get the following results:

Description | application.benchmarks/cpu | application.benchmarks/working-set | load.http/requests | load.http/latency/50 | load.http/latency/75 | load.http/latency/90 | load.http/latency/95 | load.http/rps/mean | load.http/rps/max
-- | -- | -- | -- | -- | -- | -- | -- | -- | --
connections_64 | 82 | 100 | 3,262,614 | 0.244 | 0.301 | 0.434 | 0.618 | 217,558 | 267,052
connections_128 | 85 | 106 | 3,863,221 | 0.364 | 0.566 | 0.923 | 1.146 | 257,689 | 374,230
connections_256 | 90 | 126 | 4,282,911 | 0.649 | 1.049 | 1.775 | 2.15 | 285,578 | 433,629
connections_512 | 88 | 223 | 4,563,602 | 1.263 | 2.322 | 3.184 | 3.754 | 305,524 | 417,300
connections_1024 | 90 | 1400 | 4,639,562 | 2.442 | 4.106 | 6.471 | 9.321 | 311,574 | 407,613

You can feed more requests at YARP at once, and get a better mean RPS, at the cost of request latency and working set. We should try some different values for each combination and see what effect that has on the RPS, latency and working set. This should apply to the other proxies as well as they may perform better/worse based on the load.

The issue points to benchmarks/dashboard; start by locating the dashboard's existing load configuration and connection/stream controls. Run the benchmark across the requested combinations for YARP and other proxies, then verify the dashboard exposes those selections and reports RPS, latency, CPU, and working-set results.

Written by the indexing model from the issue text.