Move benchmark orchestration from GH actions to a bot

[AdamGS]

Just moving this dicussion from Slack to make it part of the historic record.

After some effort, @joseph-isaacs and I managed to make the current benchmarking flow work for PRs coming from forks, but they can't comment on the PRs due to github's permission model and security concerns.

I've been thinking about moving that flow into a bot based one instead of using actions and labels, It will still be able to comment on PRs and do everything else we currently use, just without the limitations of gh actions permission model, and potentially it could be more flexible.
datafusion does something similar (AKA andrewlamb-bot), it looks pretty good imo, but I haven't looked at the code. IIRC Github's API is pretty well documented so I don't expect it to be a major effort once the initial issues are ironed out.

The bot will roughly have the following flow:

1. Listen on all comments to open PRs on vortex-data/vortex.
2. Once it gets a command (/bot run benchmark or something like it), it will trigger a GH action run on in that repo, but pulling the PR's branch using git or the gh cli.
3. Will run all the benchmarks, and pull the results.
4. Using its wider scoped application token, it will render the results into markdown and post them as comments on the original PR in vortex-data/vortex.

We can also use it for the post-merge benchmarks that update the website, it'll just require shifting some code over to that repo.

[alamb]

Should you wish to see the wonder 🌭 that underlies alamb-ghbot it is https://github.com/alamb/datafusion-benchmarking/tree/main/scripts#cookbook-requesting-benchmarks
(tldr it is a
python script that polls the guthub API every 5-10 seconds looking for command
Responds to commands and writes jobs to the "job queue" as shell scripts in a directory
The worker runs those shell scripts (and renames them to .done to signal completion)
I am particularly pleased because all state is stored on the file system in files (aka I don't have to worry about permissions, running databases, infra etc)
The downside is it is not at all secure so I have taken to explicitly whitelisting commands / people who can submit jobs to only those I trust