Minimize tracing-tracy allocations

~~Depends on https://github.com/nagisa/rust_tracy_client/pull/85. Will rebase once that's in.~~ Done.

~~Note that the two commits should NOT be squashed as the second one contains benchmarking code.~~

Turns out GitHub saves the PR history even when squashing, so nevermind since I feel like these commits are messier.

The one major downside of this caching is that for long-running applications which occasionally have super long field values, we have no way of reclaiming that memory. I think that's ok until someone actually runs into this issue and can tell us more about their needs. For example, maybe we offer a "clear cache" API that they could run? Or maybe they need to configure the max cache size? Not sure, so probs easiest to wait unless you think this needs to be solved (in which case I'd rather do that in a follow up PR). TL;DR: the memory usage currently scales as O(num_active_spans*max_field_value_length).

The results are in: almost double the performance!

Note that I'm testing this with https://github.com/nagisa/rust_tracy_client/pull/87 as I'll deal with the format! allocation once we have a path forward there.

~> tracy-capture -o ~/Desktop/ftzz4.tracy -f
Connecting to 127.0.0.1:8086...
Queue delay: 19 ns
Timer resolution: 19 ns
 471.09 Mbps / 18.8% =2501.45 Mbps | Tx: 563 MB | 1020.05 MB | 10.21 s
Frames: 2
Time span: 10.25 s
Zones: 4,033,823
Elapsed time: 9.93 s
Saving trace... done!
Trace size 282.4 MB (37.28% ratio)
~> tracy-capture -o ~/Desktop/ftzz5.tracy -f
Connecting to 127.0.0.1:8086...
Queue delay: 21 ns
Timer resolution: 21 ns
 498.87 Mbps / 18.2% =2744.67 Mbps | Tx: 366.32 MB | 722.33 MB | 6.67 s
Frames: 2
Time span: 6.69 s
Zones: 4,033,813
Elapsed time: 6.41 s
Saving trace... done!
Trace size 193.94 MB (34.32% ratio)

Before:

After:

nagisa / rust_tracy_client

Minimize tracing-tracy allocations #86