These scripts help generate the libcore TEST_MAPPING smoke tests, i.e. a set of
tests to run on every change, chosen to run as many as possible in less than
some time limit.

The process is as follows.
1. Do `source build/envsetup.sh` and `lunch <whatever>` as normal.
2. Run the CtsLibcoreTestCases tests to generate logs to extract timings from.
   This can be done with `atest CtsLibcoreTestCases` as normal. Make sure to use
   an appropriate device (virtual or physical).
3. Do that two more times. We'll use best-of-three timings, since sometimes a
   test takes an unusual amount of time (perhaps because of GC pause or other
   jank) and it should not be excluded for that.
4. Run the save_logs.py script to copy the logs from out/ to libcore/smoketest.
   (Empty that directory if it exists already). This is interactive and allows
   you to pick the runs you want. (If you prefer, you can run this after each
   run, rather than once after all three runs.)
5. Run the gen_smoke_tests.py script to generate libcore/TEST_MAPPING.
6. Check stdout from the script looks okay (not too many warnings, sensible
   numbers, etc.).
7. Check the generated TEST_MAPPING looks okay.
8. Do e.g. `time atest --test-mapping libcore` to check it runs okay.
9. Delete libcore/smoketest/ once you're happy.
10. Submit the new TEST_MAPPING.

The scripts take no options. There are some constants at the start you can
adjust. (These could be converted to command-line options if convenient.)

See comments in the scripts for more on how they work.

At time of writing, with the current configuration, this generates a sensible
number of classes to exclude, so the TEST_MAPPING looks reasonable. If this list
becomes too long, we'll have to find a way to simplify it, by rolling up to a
higher granularity. Given the way that atest et al are configured, that will
probably mean excluding more things.

TODO(peteg): What about PTS?