Support benchmarking of resident compilation

[retronym]

Resident (aka, multi Run) compilation reuses a global, and its symbol table,
for subsequent compilation tasks.

Currently, this mode is only used in the presentation compiler and in the
REPL compiler.

This can lead to significant savings by avoiding re-parsing/-unpickling
class files. We'd expect this to matter more for small compile batches.

Corpus	non-resident	resident	factor
vector	198ms	121	0.61
better-files	522	360	0.69
scalap	790	720	0.91

Resident compilation currently doesn't have a good for cache invalidation.
If a JAR or .class file is updated, it should throw away part of the symbol
table and re-read the classes.

The data we gather from these benchmarks will help motivate the effort to
add this cache invalidation.

It is also worth remembering that reducing the overhead of small compilation
batches is also useful for projects with large codebases. Zinc compiles small
sets of source files in an incremental compilation session.

[lrytz]

the resident method seems to be unused

[mkeskells]

can we get a breakdown of the time and memory usage changes on a phase by phase basis, as we have the instrumentation to support this

[retronym]

@mkeskells To integrate -Yprofile into the compiler-benchmark project we would need to extract the captured data programattcally at the conclusion of each compilation and aggregate it into an average across the entire benchmarking session.

One approach would be to use -YprofileDestination=tmpfile, and have a new JMH profiler that simply reads and parses that file. WDYT?

[mkeskells]

@retronym the -YprofileDestination should work for that that, recording a run sequence no as one of the columns in the standard csv output. Could do a custom recorder but need to work out what to do with GC
It also recordsGC time to enable you to prune those phases from the aggregate - a 10ms average can be distorted by a 200ms GC pause.
@rorygraves is working on a front end integration with sbt that may also be of interest, allowing to 'run until stable', and looking to isolate the unstable timings - we thing sbt is doing some background tasks