[CI] Implement queue-based approach to running kibana test suites

[brianseeders]

Re-visit this work after #44925 completes.

My initial testing for this saw full pipeline runtimes as low as 41 minutes, and this approach included creating a tarball of the entire post-build workspace and transferring it to other machines via GCS. With our latest pipeline work, we may actually be able to do this effectively without transferring workspaces, which could bring our pipeline time below 40 minutes.

General Idea (repeated for OSS and X-Pack):

1. Create a list of all test suites (e.g. individual files with tests in them), along with the config file needed to run each suite
2. Have multiple, parallel workers keep pulling from the queue of suites until all of the tests are complete
3. Re-run any suite with failed tests, to combat flaky tests

Considerations

• Invocations of FTR have 5-10 seconds of overhead, because of on-the-fly Babel transpiling, and this quickly adds up with lots of invocations for small test suites
• Starting up Elasticsearch and Kibana are time consuming, so workers should not switch between suites requiring different test configs too much. Ideally, they also wouldn't spend 1 minute spinning up ES+Kibana to run 1 test suite for 5 seconds.
• GitHub checks broken down by ciGroup wouldn't make sense anymore, as ciGroups will be gone. There are too many test suites (100s) to show them individually. What should be shown instead?
• If we're still primarily using the Jenkins UI for status/etc, these changes will make the problems worse
• Even some individual test suites take a long time to run (functional.apps.maps.es_geo_grid_source) and should be further broken up or otherwise prioritized

[elasticmachine]

Pinging @elastic/kibana-operations