PERF: Increase threashold for using binary search in IndexEngine
# Checklist

- [x] closes #54550 (Replace xxxx with the GitHub issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

# Explanation

So after a bit of research for #54550, I found that the source of the behavior is coming from PR #22826 at [this line](https://github.com/pandas-dev/pandas/blob/0f437949513225922d851e9581723d82120684a6/pandas/_libs/index.pyx#L361) and particularly this comment [here](https://github.com/pandas-dev/pandas/pull/22826#discussion_r220715797). 

In the comment, @rtlee9 makes an excellent explanation for the reason behind the threshold. The default behavior is a linear search (`O(n)`) in the pandas index and #22826 added a binary search optimization for monotonically increasing index which is in `O(m*log(n))` where `m` is the number of target indexes.

# Proposed Solution

I'm proposing we increase the limit, which was set conservatively to 5. We could at least increase it to n / (2 * log2[n]) which is derivable from m*log2[n]<n and dividing per 2 for keeping a certain margin. I'll open a PR for that.

# New results of benchmarking + homemade script

Here is a screenshot of `asv continuous -f 1.1 -E virtualenv upstream/main HEAD -b ^indexing.*Index*` output (done on Macbook Air m1, inside the docker container provided by pandas):

![Capture d’écran, le 2023-08-23 à 09 05 41](https://github.com/pandas-dev/pandas/assets/5565274/a5eda5c8-2d9a-4ebd-a337-c82f0f5094a0)

Here is also a new output for the script use to demonstrate the problem in #54700: 

```
With all at once: num_indexes=1 => 0.00048s
With all at once: num_indexes=2 => 0.00045s
With all at once: num_indexes=3 => 0.00038s
With all at once: num_indexes=4 => 0.00035s
With all at once: num_indexes=5 => 0.00035s
With all at once: num_indexes=6 => 0.00045s
With all at once: num_indexes=7 => 0.00042s
With all at once: num_indexes=8 => 0.00066s
With all at once: num_indexes=9 => 0.00049s
With all at once: num_indexes=10 => 0.00048s
```

Thanks in advance for the review!
Thanks @l3robot  > Thanks @l3robot 

Glad to contribute!