Improvements to Mesh.element_finder

[kinnala]

There is a heuristic optimization in MeshTri1.element_finder and MeshTet1.element_finder which tries to reduce the number of candidate elements where the query point may reside. The optimization logic looks for the query points inside elements whose midpoints are nearby. However, if the number of input points is large (in comparison to the number of elements), this "optimization" actually leads to a larger number of candidate elements and more memory being allocated.

• As in In mesh tri 1, remove duplicate indices but keep order. #668, take only unique candidate elements into consideration. Fixes Examples providing your own mesh and retriving the basis functions? #666.

Moreover, it was pointed out in #666 that the optimization logic does not work for some meshes with degenerate elements.

• Add a robustness test for randomized Delaunay MeshTri1and MeshTet1; compare against scipy.spatial.Delaunay.find_simplex
• Search all elements if the correct candidate is not found on the first try
• Increase the maximum number of candidate elements in MeshTet1.element_finder

While testing the new implementation it was found out that the optimization logic fails entirely for meshes that have less than 5 or 8 elements and raises error.

• Fix MeshTri1.element_finder and MeshTet1.element_finder for meshes that have a small number of elements.

Moreover, as pointed out in #646, points outside of the mesh are not detected correctly.

• Raise error if the point is outside of the mesh. Fixes element_finder and external points #646.