Improving and fixing GridTools::compute_point_locations

[GivAlz]

Hi everyone,
yesterday I had an idea on the algorithm for compute point locations. I think @tjhei will like it better, since it's the simpler one with his suggestion...but which has been then hybridized with the "use distance to avoid distant points" idea.
This has several benefits:

• code is nicer
• now, even if the "radius check" fails (i.e. we discard a point which was actually in the local cell), no new cell shall be added (so, after adding this PR to deal.II, the test of Make fe_field_function compute::point locations use the gridtools version #5411 should work just fine)
• it's faster: compared to the current version GridTools::compute_points_locations, we have a 2x speedup for random points (that's almost as good as using the other version I proposed, which was very slow on ordered points, see Added new compute point locations to GridTools #5314 ) and 2x speedup or more even for ordered points.

Moreover I tried to improve the documentation and removed the old distance factor altogether :)
Best,
Giovanni

[masterleinad]

/run-tests

[masterleinad]

Again, the failing test

	545 - all-headers/base/polynomial.h.debug (Timeout)
	546 - all-headers/base/polynomials_rannacher_turek.h.debug (Timeout)
	547 - all-headers/base/graph_coloring.h.debug (Timeout)
	548 - all-headers/base/job_identifier.h.debug (Timeout)
	549 - all-headers/base/vector_slice.h.debug (Timeout)
	550 - all-headers/base/data_out_base.h.debug (Timeout)
	551 - all-headers/base/function_spherical.h.debug (Timeout)

are very likely unrelated.

[GivAlz]

Yes, these tests are most definitely not related and, in fact, they failed because of "timeout", not of wrong output...my worry was for the other PR since fefieldfunction::compute_point_locations is used by other functions and some tests related to fe field functions are failing...but for this PR I think everything is fine so I believe it can be merged.

Thank you,
Giovanni