better buffer trim handling

[jerch]

During perf measuring with firefox I found, that a lot of runtime gets eaten by pure render features to update their internal states:

• DecorationService._handleBufferLinesTrim
• SelectionService._handleTrim

What happens currently:

• trim event is fired for every single row progress on the ring buffer (amount=1 most of the time)
• render only state updates corrected by mostly amount=1

So yeah, we have an infamous action(1) looping going on here, neatly hidden behind event cascades (which furthermore adds to the runtime). This adds 10-15% runtime for data heavy inputs in chrome, firefox profiling is currently not useable until most of #6106 is fixed.

Better idea - batch things to a single call:
As long as no rendering is about to happen, those methods above do not need to be informed. Instead we could collect the amount and do the state adjustments right before rendering. There are edges to be tracked, like from resize & reflow or any user events, that mess with terminal output state.

Refs:

• massive performance degradation #6106
• DecorationService._handleBufferLinesTrim too expensive #6120