Search and find* deprecations fixes and improvements

[nalimilan]

See commit messages.

Fixes #26145.

[mbauman]

Looks like we're also missing this deprecation:

julia> search(UInt8[1,2,3],UInt8[1,2])
ERROR: MethodError: no method matching search(::Array{UInt8,1}, ::Array{UInt8,1})
Closest candidates are:
  search(::Union{Array{Int8,1}, Array{UInt8,1}}, ::Union{Int8, UInt8}) at deprecated.jl:55
  search(::Union{Array{Int8,1}, Array{UInt8,1}}, ::Union{Int8, UInt8}, ::Integer) at deprecated.jl:55
  search(::Union{Array{Int8,1}, Array{UInt8,1}}, ::Char) at deprecated.jl:55
  …

[nalimilan]

We don't support looking for a sequence of elements in a collection (except for the special case of strings). Vector{UInt8} was the only supported type, mostly because of how string search was implemented, and it wasn't documented. If you're interested in this, it would be worth discussing possible designs, e.g. findfirst(sequence(needle), haystack), or just findfirst(needle, haystack) (which could be confusing since you could expect it to be equivalent to findfirst(occursin(needle), haystack)).

[mbauman]

Ah, ok. I was just reviewing the PR based upon what the diff showed and the behaviors of 0.6 and 0.7 — we have deprecations for rsearch(::ByteArray, ::ByteArray) but not search. Not trying to re-design a whole thing.

[nalimilan]

Ah, indeed. That's just an oversight, I didn't think about it when implementing deprecations for all existing methods. They don't give correct results since they consider the array as an element rather than as a sequence. I've added a commit to remove them.

[nalimilan]

While I'm at it, I've added a commit to return nothing rather than an empty range, as discussed on #triage last week.

[garrison]

I'm not sure how I feel about this final commit which returns nothing rather than the empty range. What is the reasoning? It seems to me like it will mean one must always test for nothing explicitly, and if a person forgets, it will lead to rare unhandled exceptions.

EDIT: Stefan convinced me; I agree that this makes sense.

[StefanKarpinski]

The reasoning is that there are patterns (e.g. regular expressions) which can match an empty range, so returning an empty range to indicate "no match" is a poor generic API.