feat(benchmarks): implement benchmarking for snapshot validation

[Rexicon226]

closes #283

i'd like a second opinion on 44d9939. i've found it pretty common that i want to build a specific part of sig and have it output as a binary.
Now it looks like this:

zig build // builds everything and installs everything
zig build benchmark // builds benchmark and runs it
zig build benchmark -Dno-run // builds benchmark and installs it

---

x19's notes:

example benchmark results (multiple values)

benchmark, read_time_min, read_time_max, read_time_mean, read_time_variance, benchmark, write_time_min, write_time_max, write_time_mean, write_time_variance, 
readWriteAccounts(100k accounts (1_slot - ram index - ram accounts)), 172156041, 158767959, 162868245, 15183799545214, 303852750, 286908417, 292925858, 39820330697776, 
readWriteAccounts(100k accounts (1_slot - disk index - ram accounts)), 165480250, 156170500, 160821658, 7611019088428, 319935833, 286708833, 304248199, 113169780175088,

NOTE: for multiple value outputs its not human readable at all - but i think thats ok -- most of our confirmations of speed ups/slow downs shouldnt be human checked, it should be computed and the increase/decrease should be human checked (which this PR allows for you to do easily)

[0xNineteen]

just to have it written down:

we chatted offline and decided to :

• modify the benchmarks to support multiple return values
• add an option to output the results in a more csv-friendly format to make comparisons across different runs easier (can use google sheets to copy and past the output with a new column = columnA - columnB to get the change in performance easier (compared to manually doing it which is error prone and not a good use of time), eg:

    // pub const BenchResult = struct {
    //     BenchmarkAccountsDB.read_time: usize,
    //     BenchmarkAccountsDB.write_time: usize,
    // };

    // '--csv' flag:
    // benchmark name, write_time, read_time
    // readWriteAccounts(100k accounts (1_slot - ram index - disk accounts)), 35.868, 32.22,

[0xNineteen]

closing to move progress to new branch