Docs improvement to help interpret test outputs and how that estimate VUs required to reach a certain rate

Nobody has claimed this yet.

Based on https://community.k6.io/t/getting-very-low-rps/5649/, https://community.k6.io/t/load-test-using-one-user-id-at-a-time-for-each-user-and-iteration/5626, and https://community.k6.io/t/k6-and-the-k6-reporter-do-not-log-accurately-highly-concurrent-requests/5600, help to interpret why the iterations/s or VU/s are not the expected, and how to estimate the `preAllocatedVUs` (to avoid having to define a `maxVUs` - except in cloud?) would be useful.

We might benefit from making it easier for k6 to allocate the required VUs for a [constant-arrival-rate](https://k6.io/docs/using-k6/scenarios/executors/constant-arrival-rate/). It might not be easy as the number of VUs will depend on the URLs under test latency, how this also varies with increasing load...

For [ramping arrival rate](https://k6.io/docs/using-k6/scenarios/executors/ramping-arrival-rate/) I think we could add what we have in k6-learn about the [ramping effect](https://github.com/grafana/k6-learn/blob/main/Modules/III-k6-Intermediate/08-Setting-load-profiles-with-executors/Ramping-Arrival-Rate-Exercises.md#ramping-effect).

In the meantime:

- In https://community.k6.io/t/getting-very-low-rps/5649/3, based on the latency and the test outputs, we could help users realize when the number of VUs is too low, and/or the test duration too small.
- There is a warning in the logs when there will not be enough VUs (`WARN[0000] Insufficient VUs, reached 2 active VUs and cannot initialize more executor=constant-arrival-rate scenario=k6_workshop`). However, the user might only be looking at the final report. And miss that warning.
- In https://community.k6.io/t/k6-and-the-k6-reporter-do-not-log-accurately-highly-concurrent-requests/5600/10 the user (and myself) was also not interpreting the ouput
> The main signal of that is the slow iteration_duration average time, which is 40 seconds.
- https://community.k6.io/t/load-test-using-one-user-id-at-a-time-for-each-user-and-iteration/5626/ probably points to something we can clarify in the docs.

I'm not sure what we are missing in the docs, if we are. I'm just opening this to start the discussion in case we can improve something.

Read the constant-arrival-rate and ramping-arrival-rate executor pages, then compare their guidance with the k6-learn Ramping-Arrival-Rate-Exercises.md section and the linked community examples. Done means the docs explain interpreting iterations/VU output, insufficient-VU signals, latency effects, and preAllocatedVUs/maxVUs estimation.

Written by the indexing model from the issue text.