fix(gc): try to not run gc when there is not enough time before the next timer

[ammmze]

This is my attempt to address Timer Too Close errors on some slower machines. Through some debugging that started with something @KevinOConnor pointed out in #6784, I observed a correlation between generation 2 collection happening at the same time as homing moves (in particular during happy hare drip/homing moves...with happy hare the user will experience many more "homing" moves than a standard non-mmu enabled printer because it "homes" filament to various sensors each time filament is swapped. I found that on my Orange Pi CM4, the generation 2 garbage collection takes between ~150-300ms depending on whether I have the shake and tune module enabled. Based on the discussion in #6784, those homing moves require low latency (<100ms) communication. So having gc that takes longer than this 100ms (which would block all other threads) is problematic. More details about my setup can be found here.

What I am doing here in his PR is tracking how long each generation garbage collection takes (with a cap of 90% of the largest free time we've seen). With this information, we can prevent doing garbage collection if there's a possibility that gc will take us past the next scheduled timer.

I am open to other ideas if you've got any. I don't think my solution is in any way bullet proof...there's still a possibility that a long running garbage collection could take too long and take us past the next timer, but I think it will be less likely.

I will acknowledge that standard klipper does do garbage collection much less frequently, but the reality is many people have extra modules like cartographer, led effects, happy hare, etc. While it would be nice if these all did their best to avoid leaving garbage for the garbage collector, the reality is that it would be a large effort and different communities have varying levels of knowledge to make this happen. So I think we should try to accommodate the best we can.