Fix equality for one-element ranges

[sostock]

#32348 made zero-element ranges compare equal, but some types of one-element ranges do still not compare equal if their step is different (cf. #29421 (comment), thanks to @ti-s for pointing this out). This PR fixes that.

As discussed in #29421, this should be backported to 1.5. Should this be mentioned in the NEWS.md/HISTORY.md item for #32348?

[KristofferC]

@mbauman, what is there to triage here?

[mbauman]

It's just a pretty big behavior change for a backport. I personally am fully in favor of it getting backported — and maybe it's not controversial — but I thought it'd be worth talking about. Perhaps simply a PkgEval is enough:

@nanosoldier runtests(ALL, vs = ":master")

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt

[StefanKarpinski]

It seems like a very buggy/wonky situation to have changed the zero-length behavior and not the one-length behavior. Definitely in favor of backporting this as a bug fix.

[mbauman]

PkgEval results seem to be pretty good (and just noisy failures), but just out of curiousity:

@nanosoldier runtests(["BilevelJuMP", "CodeTransformation", "DelayDiffEq", "Juniper", "MatrixProfile", "Pajarito", "Reactive", "TensorToolbox", "WinRPM"], vs = ":master")

[JeffBezanson]

Agreed we should backport it.

[nanosoldier]

Your package evaluation job has completed - no new issues were detected. A full report can be found here. cc @maleadt