feat: Add findInRange and findInRangeBinarySearch functions to Int and Nat.

[Andrei1998]

Following discussions in #375, this PR implements findInRange and findInRangeBinarySearch functions for Int and Nat, including unit tests.

Note that findInRangeBinarySearch can be indirectly used to binary search on collections with constant-time random access by indexing into such collections inside the predicate.

Part of addressing issue #382.

[rvanasa]

Implementation LGTM. I wonder if it might be difficult for developers / LLMs to understand when/how to correctly use this function. Maybe renaming to findInRangeSorted() could help clarify?

[Andrei1998]

I do have similar feelings on the naming here (somehow, no matter how you call it, it won't be completely compelling). Find in range sorted would make sense when calling it on some array/list etc., but would seem a bit off when using it to binary search on an abstract predicate like when computing a square root with binary search (ranges are already sorted, so the sorted here would refer to the predicate being "sorted"). Perhaps the most theoretical name would be findInRangeMonotonePredicate or findInRangeMonotone. The latter actually doesn't sound that bad (it's basically your suggestion but abstracting away the sortedness into monotonicity, which is what the method ultimately needs). Wdyt?

Leaving the naming aside, I think it's actually a good idea to make the docstring more "useful" (i.e., with standard use-cases like binary searching on an array and binary searching for the square root). Would that perhaps also help? This could still have a downside: if we later merge a PR like yours introducing collection-specific binary-search methods (which would be nice to have because of inlining and removing some bloat from the interface for those specific use-cases), users might be tempted to use the method in the enhanced docstring rather than looking up the collection-specific method.

[rvanasa]

Maybe we could merge #375 first, since we would include those functions either way. I like the idea of showing more real-world-like examples in the doc comments.

[Andrei1998]

That works from my side. I am wondering whether we then want to also make the functions there do "find first" (C++-like) instead of "return position where it would be inserted" (Rust-like). It's true though that you will be able to do "find first" with these Int/Nat functions anyway, so maybe the diversity/inconsistency is actually good.