Add memory benchmark through jemalloc allocation trace

[vinistock]

Not exactly #864, but a decent step towards it if we decide to move forward

I've been suspecting that our memory measurements using RSS are not super precise. Based on my understanding, max RSS represents the peak memory used by the process. Since we spawn multiple threads during indexing, I assumed that the peak would probably occur during that phase, but that's not what we're interested in. Instead, we want to know the amount of memory that the final graph consumes.

This PR adds a memory benchmark. The way it works is:

1. Use jemalloc as the global allocator in a benchmark target. Jemalloc allows tracing allocations across epochs, which gives us the opportunity to analyze the diff of bytes between epochs
2. Add the benchmark target. Using [[bench]] means that the code is always built in release mode, but can use development-only dependencies. The executable builds the graph and compares the memory being used before and after dropping it

I also added a convenience script that runs the benchmark for a given path and optionally accepts a --compare argument. When using --compare, it just runs the benchmark against main first to allow comparing the results.

In all workspaces I tried, the max RSS approach overestimates the amount of memory being used:

• Core: 46%
• Ruby LSP: 195%
• Rails: 52%