performance monitoring and benchmarking

Occasionally I hear that pyuvdata is slow, though without further investigation this complaint is impossible to decouple from the size of the data being read.* However since we do not currently track execution time of our various tasks, it is possible for a change to be introduced which increases execution time. This is difficult to monitor at scale because large files and extended execution times are not easily supported within the current testing infrastructure. Here are a few possible things we could do:

1. Monitor the execution time of all tests. This is a crude metric as we know that execution time can be affected by exogenous factors related to the underlying cloud infrastructure or install times.
2. Monitor the execution time of specific existing tests. This would be a more precise datum than all tests which would expose things that grossly affect read time, but since the test files are small would not expose issues that scale badly with times, freqs, etc.
3. Add tests which focus on timing but use the existing test files. This could include things like reading the file many times and averaging the read time, generating a large number of files and concat-read them, etc.
4. Setups that require more resources. Its not clear what the break point is.

*The following is a digest of a discussion on the 3 Dec 2019 pyuvdata telecon.

The issue names no specific files, tests, or entry points. First review the existing test files and testing infrastructure, then determine which benchmarking approach is accepted; the work is done when a defined, repeatable way to detect execution-time regressions is agreed and implemented.