Continous Perfomance Testing

We don't have a mechanism to catch performance regressions (such as #198).

We use BuildKite to test all PRs are *correct*, but we optimize its configuration for Frugality. We run multiple tests in parallel which allows us to use a single bare-metal instance to run all tests, but the performance numbers we can get from there would be fluctuating, based on other builds running on the same time.

The issue names no files, tests, or entry points. Start by reviewing the existing BuildKite configuration and how performance tests are run; done means defining and implementing a reliable mechanism that detects performance regressions without measurements being distorted by concurrent builds.

Written by the indexing model from the issue text.