Add benchmarks for experimental and make the compiler 2x faster

[mcy]

I added some simple benchmarks, which compile the googleapis Buf module in a number of different settings. This allowed me to stare at flame graphs really hard and remove various bottle necks (or places where Go failed to optimize correctly).

This mostly involved chasing down places where Go failed to inline, devirtualize, or stack-promote. Including the new interning algorithm, the experimental compiler is now on-par with the old compiler. Hot recompiles are, unsurprisingly, orders of magnitude faster, something we've already seen in LSP.

With my optimizations, the lion's share of work is actually in building FileDescriptorProto, which is not currently parallelized. Building a googleapis FDP with SourceCodeInfo takes about a full second, compared to less than a second to do in-memory linking. 60% of that is generating the SourceCodeInfo.

Other fun facts:

1. Originally, the slowest thing was the lexer, due to escape analysis failing inside of internal/trie.
2. The slowest part of lowering is flattening the AST and building the IR scaffold, followed by options evaluation.

One concerning thing I noticed, which I kind of expected, is that most things that return seq.Indexer seem to inline, but then their return values escape to the heap anyways. It's not clear to me what the cause is. I suspect that seq.Values is the culprit, and there may be a Go compiler bug around devirtualization here. I probably need to stare at the assembly to puzzle it out.

[doriable]

Should we indicate when this commit was last updated in either the package docs or in a comment above the generate invocation and/or should we have a make target that manages/upgrades this (I assume we mostly care about updates, it seems unlikely that we would be downgrading this)?

[mcy]

Nah, git history takes care of that.

[doriable]

This looks good to me, stamping in advance of resolving the CI issue.