Benchmark symbol indexer about metals

[ShaneDelmore]

For a very large code base I don't believe in memory indexes are going to hold up. I did some testing today on tens of thousands of semanticdbs and found that scaling per 10k semanticdb documents was roughly:

To load semanticdbs that have been previously calculated:
1 minute to load
1.5GB RAM to load
1GB RAM used after garbage collection with jvm string deduplication enabled
4s added to garbage collection time per 10k semantic documents indexed

Without having at least a 1.5x more heap available than will be eventually needed load time went through the roof, on one test after half an hour I just gave up. Adding more heap (over 10GB) got it down below 10 minutes again.

For small to medium size projects the in memory solution may work out just fine but for very large code bases it is not going to work.

[olafurpg]

Fixed in #332. Numbers from my machine are listed here https://github.com/scalameta/metals/blob/master/metals-bench/readme.md

At least the build has benchmarking infrastructure and new features will be benchmarked before getting merged to ensure that performance is good even for large code bases.