Enable fan for time period before and after bridge

[appideasDOTcom]

Feature Request Sometimes, a bridge is made in a very short period of time, and there is not a sufficient amount of time for cooling. This is particularly troublesome for plastics that should not have continual cooling, but need for a fan to be enabled slightly more than briefly to prevent bridges from sagging.

The solution I'd like I would like to be able to set a time period (e.g. number of seconds) to enable the parts cooling fan before and after a bridge is made. This would logically fit above or beneath the current "Bridges fan speed" setting on Filament Settings > Cooling.

Alternatives I've considered From the end-user's perspective, I can't think of a better solution. I don't have a concept of the difficulty of pulling this off in slic3r's code.

A couple of potential alternatives:

1. This could, perhaps, be specified as a "minimum bridge cooling time," which could mean that the fan would be enabled for at least "x" seconds during any bridge, but that seems like it might be more confusing to users.
2. Possibly an easier option to pull off (from your perspective) would be to add a checkbox to enable the parts cooling fan for the entirety of any layer that has a bridge. Although this isn't ideal, it should resolve the problem. Having only a single layer that has been continually cooled "shouldn't" compromise the integrity of the printed piece in most cases.

Additional context I often print in PETG, so cooling is highly discouraged (layer adhesion is greatly reduced resulting in significantly more brittle printed parts), but small-ish bridges don't come out well unless I am anticipating them and happen to be sitting around with a portable fan to manually cool as they are being made. My manual testing has convinced me that this problem would be resolved if I were able to enable the parts cooling fan for 15-30 seconds before and after troublesome bridges.

[lordofhyphens]

So in order to make something like this happen, the following needs to occur:

• Need to know where any bridge is in the print (this is done).
• Need to be able to look back N print moves, where N is variable based on the prior move speeds (this is to get to time). This information is likely present in the MotionPlanner and/or GCodeWriter.
• Need to be able to close he window N print moves later, (see above for definition of N).
• Need a configuration item to specify the length (this is trivial). Such a feature would break hard if there's firmware limits to speed that's slower than expected.

@appideasDOTcom you could probably implement this via a post-processing script, combined with code annotation. You'd need to implement the command window and read the F commands to get the speed.