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

[mauro3]

1. Checks bounds on the more low-level searchsorted* methods. At the moment
   an error like this is possible:

julia> searchsortedfirst([1:10], 5,  -10, 7, Base.Order.Forward)
zsh: segmentation fault (core dumped)

I corrected this by adding a bounds check. The alternative would be to rename the low-level searchsorted* to, say, _searchsorted* and not export them. (my understanding is that no exported methods in Base should seg-fault unless they are labeled unsafe_)

TODO: The same goes for the low-level select! and sort! methods, which also do not check bounds. But some of them are recursive and a bounds check is only necessary on the first execution. Maybe renaming would be better? @StefanKarpinski, I think you updated sort.jl most recently, maybe you can comment. Let me know what would be the preferred solution and I can update this PR.

Here an example of a sort! bug:

julia> a = rand(2)
2-element Array{Float64,1}:
 0.0272557
 0.200126 

julia> sort!(a, 1, 15, Base.Sort.QuickSort, Base.Order.Forward)
2-element Array{Float64,1}:
 9.88131e-324
 9.88131e-324

2. Removes the step(r)==0 tests as ranges cannot have 0 steps (I think)

[kmsquire]

Even though those particular function are not documented and not expected to be called by users, this is still the right thing to do. Good catch!

[mauro3]

Thanks Kevin.

I cannot reproduce the Travis failure on my local clang build, so not sure what that is about.

[JeffBezanson]

Yes, the lack of bounds checks was due to these being internal forms of functions. It also used to be possible to have ranges with step 0.

I think we are fine with the unsafe, undocumented internal forms of sort!. This change is fine though.