Improve editor performance with many timeline ticks present

[EVAST9919]

This particular example looks unrealistic, but it's allowed via editor means: we can set bpm to 10000 and zoom out as far as possible.

981ee54 fixes transforms allocation overhead.

34a5e2d is the same approach as in #27562. While the whole timeline is moving, we can guarantee that with the current implementation almost all ticks in the tree (except 16 ones used as a buffer) will be visible. I think it's okay to allow some overdraw including the fact that we are CPU-limited in most common cases anyway. Another bunch of problems comes from the fact that these ticks are rounded, so we can't batch them properly, but this should be fixed with SSBO, I believe? Also I would love to use DrawNodes to draw these, but again: we can't draw rounded rectangles directly.
Potential best approach will be some sort of BufferedContainer usage, though this will require major changes.

	master	pr
paused
playing

[peppy]

Silly benchmark results.

Please show real-world cases in the future. I don't know what the hell that timeline is showing but it should not be allowed.