Performance fixes for larger files

[Doublonmousse]

Fixes #1436 (and maybe #1438, waiting on a response)

• use push_repeat for background nodes : This seems to reduce RAM usage and buffer uploads to the gpu so there's more headroom for the rest of the nodes
• use the rtree to speed up regenerate_rendering_in_viewport_threaded : We use the rtree to get the strokes in the viewport without recalculating any stroke bounds, and get the ones not in the view by iterating on keys and using a hashmap to filter out the previously selected ones

On that subject, it seems we could use a https://docs.rs/slotmap/1.0.7/slotmap/sparse_secondary/struct.SparseSecondaryMap.html for the render components and/or be smarter on clearing the render_comp components of strokes (we know there's no work to do if we have x strokes in view that we just initialized the rendering components and x strokes in the rendering component slot)

I've updated the rtree to only keep bounds for visible strokes (so trashed strokes are removed from the tree)

• use rtree for update_content_rendering_current_viewport calculations Once again, using the rtree to calculate document bounds is much faster

I've also added to the visual debug mode a way to see the envelope of the whole rtree (marked by orange bounds)

[flxzt]

Only storing non-trashed strokes in the R-Tree is problematic and will require additional changes in other parts - essentially everywhere where one of the methods of KeyTree are used (like keys_in_bounds(), keys_intersecting_bounds() etc. Right now they are all used under the assumption that all strokes are included in the tree. Did you consider this?

[Doublonmousse]

I'm trying to rely more on the keytree to get stroke bounds whenever possible (as calculating a bunch of stroke bounds on each event is potentially pretty expensive).

Testing the two keytree solution, I'm encountering quite weird results with the splitting eraser

[Intranox]

I'm not entirely clear on the issues arising from this pull request. I've been using a version containing these fixes for some time now, and in my daily use, I haven't encountered any problems. In fact, I can say I've rediscovered a software that finally meets my needs. I take notes that can span several pages, and as the content increases, it becomes completely impossible to continue on the same paper. However, I think it's very important for an app like this to be able to take as long notes as I want. With these fixes, this has been possible, and I've also rediscovered a general fluidity that wasn't there before (even in scrolling or the selection tool, for example).

[flxzt]

good to know, but not really relevant for the technical discussion this PR should focus on @Intranox