Don't load the whole measurement file into memory at once -- it may be very large

This change is to scan the measurement files line-by-line, rather than loading the whole thing into memory as a giant string.

With a large test suite, the measurement files can get rather large (30MB for half of our suite). 

If we change the "invoked" numbers to be `\n` delimited instead of `;` delimited, then we can use the standard line-by-line buffered file reading libs to read in the statement ids instead of needing to read a huge string then doing a (memory-expensive) `split` into a huge array.

Note that this creates a binary incompatibility -- you will need to recompile `sbt-scoverage` (no source changes are needed in that project).

This takes my test run (sbt scoverage:test, without a "clean") from 1m28 to 1m22. This number may overstate the improvement (or hopefully understate it); I haven't done very many tests.

## Performance measurements digression

Just for interest, while I'm measuring performance, here are some numbers from our fairly large multi-threaded test suite (477 tests). Note that this is just the "test" part, not the integration test part. This is on my Windows dev machine, using Java 6 and Scala 2.10.3

Time to run "`sbt scoverage:test`" without a clean (i.e. after a previous run has done all the compilation):
 * At revision 2acb521e = 10m52
 * After today's 4 pull requests = 1m22

I don't quite believe this, but I have just checked and re-checked this, and it seems like "`sbt test`" takes _longer_ than "`sbt scoverage:test`", at about 2m06. I'm going to have to dig into that!

(The variance of each of the measured numbers above looks to be around 5%)