Memory leak noise due to temporary allocator

[graphitemaster]

Is your feature request related to a problem? Please describe.
Leaking memory on exit for the temporary allocator (while fine) is also frustrating when using memory leak checking tools like ASAN (possible by passing the bitcode directly into llc) and Valgrind, an opt-in method for debugging purposes would help eliminate some of that noise.

Describe the solution you'd like
Some compilation option (for debug builds mainly) that augments main and calls runtime.default_temp_allocator_destroy(&runtime.global_default_temp_allocator_data) just before returning. The same behavior already exists for thread exits since runtime.global_default_temp_allocator_data is @thread_local, so it's actually just a case of forgetting it for the main thread (not application managed).

Additional context
I'm perfectly aware that this is not a memory leak, it's intended behavior and we should let the OS cleanup this memory in release builds, but during development I make a lot of extensive use of memory leak check tools to ensure I'm not silently introducing such problems. The noise of these temporary allocation leaks really slows me down because it's not immediately obvious at first that it's a temporary allocation. It's also non-trivial to hide these false-positives from Valgrind (I tried with a suppression file, but the thing behaves as a ring buffer so the tracking after reuse tends to get the tool confused), it's also totally impossible with ASAN due to how I'm tricking that into instrumenting the bitcode. I'm much more productive when adding runtime.default_temp_allocator_destroy(&runtime.global_default_temp_allocator_data) at the end of main. There's also the question if we should just do this anyways since we already do it for threads (otherwise they would leak), just to keep everything symmetrical?

[gingerBill]

I've added a way to clean-up the runtime in 7aac8df