Fix Epeck_d spatial searching compilation

[UtkarsHMer05]

Summary

Fixes Spatial Searching compilation failures when using Epeck_d.

Iterator_from_indices already implements the operations required by a
random-access iterator through increment(), decrement(), advance(),
and distance_to(), but advertised only bidirectional traversal.

This change:

• advertises random-access traversal;
• adds an explicit operator[] returning the iterator reference type,
  avoiding the inherited Boost proxy result;
• adds a regression test for static and dynamic Epeck_d;
• covers Fuzzy_iso_box, Fuzzy_sphere, Kd-tree insertion, search,
  removal, and size verification.

The regression test is enabled when Eigen support is available.

Fixes #9534.

Validation

Validated from a clean worktree based on public/main commit
10968626f93fca92bd0b2b934c2899819e732bb1.

• Confirmed the regression fails on the unchanged baseline with the
  expected iterator/random-access compilation errors.
• Built all 17 Spatial Searching test targets in Release.
• Built all 17 Spatial Searching test targets in Debug.
• Built all 4 NewKernel_d test targets in Release and Debug.
• Ran the new regression in Release and Debug.
• Ran assertion-enabled Epick_d, Epick_d_eigen, test_bbox_d,
  remove, and Splitters tests.
• Ran the tri2 Debug test with 1,000 points.

[mglisse]

This makes sense to me.
Note that it does not completely fix #9534: Fuzzy_iso_box.h uses an operation not guaranteed by the concept, so either that file or the concept needs to change, although that can be done in a separate PR, I don't care.

[afabri]

Fuzzy_iso_box.h uses an operation not guaranteed by the concept

Hello @mglisse : What concept and what operation?

[mglisse]

Fuzzy_iso_box.h uses an operation not guaranteed by the concept

Hello @mglisse : What concept and what operation?

See #9534 (comment)
(operator- on iterators, and the Kernel_d concept).
Ah, no, I now see that the relevant concept is SearchTraits, which does require the iterator to be random access, something stronger than the Kernel_d concept guarantees.
If the only reason for this random access requirement is the one call to operator-, I think it would make sense to replace it with std::distance (or possibly Point_dimension_d, but that would require adding it to SearchTraits) and lower the requirement, but it is less important once the kernels we document as satisfying the SearchTraits concept actually satisfy it.

[afabri]

So let's undo the change to RandomAccessIterator and use std::distance(). @UtkarsHMer05 can you do that please, or make me collaborator so that I can make the change in your PR.

[mglisse]

So let's undo the change to RandomAccessIterator

You mean what this PR is currently doing? Why? Since this iterator for this kernel can easily be made random access, it seems like a good idea to make it random access, whether users of the iterator need it or not.

[afabri]

You are right. As this is model we know that it is random access. So all we have to do is to replace the minus by std::distance() which exploits random access if available.

[UtkarsHMer05]

Thanks. Maintainer edits are already enabled on the PR. I can make the agreed std::distance() change myself, but if you were planning to push it directly, please let me know so we don't duplicate the work. @afabri

[afabri]

@UtkarsHMer05 please go ahead. Best, Andreas

[UtkarsHMer05]

@afabri Done, thanks. I kept the random-access iterator change and updated Fuzzy_iso_box to use std::distance(). I also revalidated the issue_9534 regression and all 17 Spatial Searching targets in both Release and Debug.