Perform server occlusion culling as spatial and temporal sampling

[lhofhansl]

This changes the current occlusion culling to a sampling approach.
Sampling is spatial, in that it sends a couple of rays to a random point inside the target block.
Sampling is also temporal in each round of going through map send cycle another rays is sent.

• Goal of the PR
  Improve both performance and accuracy of occlusion culling. Remove the hack that requires encountering two solid nodes before declaring a block invisible - not needed with the sampling.

• How does the PR work?
  Instead of a fixed set of culling rays, send a set of random rays.

• Does it resolve any reported issue?
  No. Although sometimes we complain about occlusion culling being inaccurate.

• Does this relate to a goal in the roadmap?
  No

• If not a bug fix, why is this PR needed? What usecases does it solve?

To do

This PR is Ready for Review (and for Testing)

How to test

Load any world. Set a large viewing_range (like 1000), and observe how the world is loaded.
Notice that blocks near-by are culled fairly accurately, whereas in the distance some "holes" are visible that filled in over time.

Whether this is annoying or not is subjective, so please test and let me know.

[lhofhansl]

Any takers for testing?
I know doing this randomly seems weird, but it is both more accurate and faster.
If we wanted to we could even trade accuracy for performance.

[lhofhansl]

I just realized the same code is used on the client (when client_mesh_chunk is < 4 and/or the viewing_range is all).

Unlike on the server, on the client the culling is not "additive". So on the client it needs to be deterministic or it leads to flickering.

Hmm... I could have slightly different client and server implementation (in clientmap and servermap, resp.), but I am starting not to like this as much anymore.

[lhofhansl]

I separated client and server side occlusion culling. The client part is back to the original, completely deterministic, the server accumulates blocks by sampling (for accuracy and performance).

[lhofhansl]

I might just close this...

[lhofhansl]

Closing this in favor of #14212.
In turns out the main improvement from this is using needed_count of 1 when sampling, and #14212 achieves that as well.