Revert "Boundschecks for searchsorted & remove step(r::Range)==0 tests"

This reverts commit 10e51e5bcfb35a3a159ecf4934c3f074900f844e.

Originally merged by 2d5dbf35b63e0fae9a741184bc27c53493d7474c, this is
incorrect in a number of ways.

The searchsorted* methods with explicit lo and hi indices are an not
part of the public API for these functions. Thus, the correctness of
the bounds given don't need to be checked – that is up to the caller.
If we decide to expose the ability to call searchsorted* with explicit
start and end indices, there should be a better API for that which
doesn't require passing an Ordering object and which checks bounds.

In particular, this broke the old behavior of searchsorted when the
value that's being searched for is not in the array. Fix #7916. Also
added somes tests to make sure this doesn't regress again.

At the time this was committed, I think that ranges could actually
have a zero step – there was a reason for that check to be there.
This may no longer be the case, but since it's cheap to check, we may
as well handle it correctly and decouple the correctness of the
sorting functions from a detail of the range implementation.

Conflicts:
	base/sort.jl