expose findfirst findnext for UInt8 vector

[Moelf]

fix #37280

[KristofferC]

Should these be moved away from the string file now?

[nalimilan]

Thanks! This makes sense. I have a few remarks:

• It sounds like this method should eventually work for any AbstractVector. The fact that only UInt8/Int8 are supported is due to an implementation detail. It's probably OK to start with a restricted method though, and generalize it later.
• We should measure the consequences of this addition for the API if we want to generalize this. With this PR, findfirst(pattern, collection) will mean "look for the sequence pattern in collection". Currently, we have findfirst(pred::Function, A), findfirst(ch::AbstractChar, string::AbstractString) and findfirst(pattern::AbstractString, string::AbstractString). The methods added by this PR are consistent with the third method, i.e. the two arguments collections, and we are looking for a sequence. Do note that it is at odds with the second one, where the first argument is a single element. This is OK for strings as there's no ambiguity, but in general with findfirst(x::AbstractArray, A::AbstractArray) you cannot know whether x is supposed to be a sequence or an element since A could be an AbstractArray{<:AbstractArray}. So if we go with this PR, we will renounce to the possibility to treat x as a single element, e.g. we'll have to keep writing findfirst(==(1), [1, 2]). I think that's OK since the syntax is relatively short, but let's be aware of this decision.
• Finally, findlast and findprev should probably be implemented in this PR for consistency (I think _rsearch allows doing this).

[stevengj]

So if we go with this PR, we will renounce to the possibility to treat x as a single element

Not as long as this is restricted to a small set of element types. I agree that this will come up in a hypothetical future PR where we generalize this to find(pattern::AbstractArray, a::AbstractArray), however, but we could discuss that question in a future issue.

[Moelf]

As suggested by @stevengj , shrinking original _nthbyte and then defined a general version for AbstractVector to minimize the changes for _searchindex. Added tests for OffsetArray. @KristofferC would you suggest a proper place for these code? Since it's no longer just String, I'm thinking base/array.jl maybe

[Moelf]

@nalimilan I have added findlast and findprev and their tests now, thanks for the comment. Yes, I was surprised when I first encountered that, for example, findfirst(3, [1,2,3]) doesn't work. But I think it is fine since ==(x) is a nice and clear way of saying "treat x as a single element".

[Moelf]

Took the suggested approach by @stevengj : shifting _i by i = Int(_i) - (firstindex(s) - 1) inside _searchindex and _rsearchindex to keep most of the logic unchanged. In any case please let me know if more edge case tests are needed.

[Moelf]

I believe this can be merged now (before another news merge conflict occur)

[stevengj]

Thanks!

[vtjnash]

When squashing and merging these commits, please try to fix up the commit message to contain only the relevant information. This one just had a rather long list of repeated:

    * Update base/strings/search.jl
    
    Co-authored-by: Milan Bouchet-Valat <[email protected]>

and it makes git log a slight bit harder to scroll past.