Fix #2266 by sorting regions after render list generation

[douira]

This fixes #2266 by sorting regions after render list generation. The summary of the bug is that it happens because from certain points of view, the frustum is such that the order in which two regions are visited by equally distant sections depends solely on their order in the queue. See the analysis here for more details and images.

My measurements suggest that sorting regions by distance takes around 5µs and in total generating render lists takes around 1200µs for this scene. So the cost of sorting regions is around 0.5% which seems very acceptable. Measuring something that only takes 5µs with nanoTime is probably not the most precise, but it's averaged and very fast either way.

[jellysquid3]

Seems fine to me.

[douira]

Renamed those methods, good to go now.

[MeeniMc]

confirm it fixes #2266

[douira]

I've added code to sort sections as well since they were suffering from the same problem as regions, also caused by subtle errors in the ordering produced by the bfs near the frustum boundary.
In my test scene with 4875 sections, the render list finalization only takes 24µs, of which 7µs are spent on region sorting and the rest on section sorting.