[Bug #19426] Fix endless `Range#step` with `#succ` method

	Fix regression when testing inclusion in unbounded ranges

	Caused by 04a92a6764bf678919cf4b68a27496a39d6b886a.  This treats
	unbounded ranges of arbitrary objects the same as how unbounded
	string ranges are treated:

	  (..x)  === y  # (y <=> x) <= 0
	  (...x) === y  # (y <=> x) <  0
	  (x..)  === y  # (x <=> y) <= 0

	Fixes [Bug #19864]
	---
	 range.c                 |  9 +++++++++
	 test/ruby/test_range.rb | 23 +++++++++++++++++++++++
	 2 files changed, 32 insertions(+)

	Extract range type check functions

	---
	 range.c | 55 ++++++++++++++++++++++++++++++++++++-------------------
	 1 file changed, 36 insertions(+), 19 deletions(-)

	[Bug #19533] Fix infinite range inclusion with numeric value

	---
	 range.c                 | 10 +++++++---
	 test/ruby/test_range.rb |  2 ++
	 2 files changed, 9 insertions(+), 3 deletions(-)

	[Bug #19533] Add spec of infinite range inclusion

	---
	 spec/ruby/core/range/case_compare_spec.rb | 6 ++++++
	 1 file changed, 6 insertions(+)

Prior to this commit the `OPTIMIZED_CMP` macro relied on a method lookup
to determine whether `<=>` was overridden. The result of the lookup was
cached, but only for the duration of the specific method that
initialized the cmp_opt_data cache structure.

With this method lookup, `[x,y].max` is slower than doing `x > y ?
x : y` even though there's an optimized instruction for "new array max".
(John noticed somebody a proposed micro-optimization based on this fact
in https://github.com/mastodon/mastodon/pull/19903.)

```rb
a, b = 1, 2
Benchmark.ips do |bm|
  bm.report('conditional') { a > b ? a : b }
  bm.report('method') { [a, b].max }
  bm.compare!
end
```

Before:

```
Comparison:
         conditional: 22603733.2 i/s
              method: 19820412.7 i/s - 1.14x  (± 0.00) slower
```

This commit replaces the method lookup with a new CMP basic op, which
gives the examples above equivalent performance.

After:

```
Comparison:
              method: 24022466.5 i/s
         conditional: 23851094.2 i/s - same-ish: difference falls within
error
```

Relevant benchmarks show an improvement to Array#max and Array#min when
not using the optimized newarray_max instruction as well. They are
noticeably faster for small arrays with the relevant types, and the same
or maybe a touch faster on larger arrays.

```
$ make benchmark COMPARE_RUBY=<master@5958c305> ITEM=array_min
$ make benchmark COMPARE_RUBY=<master@5958c305> ITEM=array_max
```

The benchmarks added in this commit also look generally improved.

Co-authored-by: John Hawthorn <jhawthorn@github.com>

Beginless ranges previously raised TypeError for this case,
except for string ranges, which had unexpected behavior:

  ('a'..'z').include?('ww') # false
  (..'z').include?('ww') # previously true, now TypeError

Use of include? with endless ranges could previously result
in an infinite loop.

This splits off a range_string_cover_internal function from
range_include_internal.

Fixes [Bug #18580]

Fixes [Bug #18983]

[Bug #18994]

[Misc #18891]