Before this commit, find_next() will just use the default implementation
of looping over each element. When find_next is called without a
function filter as first argument, we *know* that semantics are to find
elements x satisfying x != 0, so for sparse matrices/vectors, we may
only loop over the stored elements.

Some care must be taken for stored zero values; that's the reason for
the indirection of _sparse_find_next (which only finds the next stored
element) and the actual find_next (which does actual non-zero checks).

…ted(...,lo=,hi=)

(Use git blame -w for finding the non-whitespace edits to
this code.)

This fixes a few merge conflicts resulting from other additions to
the sparse codebase.

…e explicit

Since we now need explicit predicates [1], this optimization only works
if we know that the predicate is a function that is false for zero
values. As suggested in that pull request, we could find out by calling
`f(zero(eltype(array)))` and hoping that `f` is pure, but I like being
a bit more conservative and only applying this optimization only to the
case where we *know* `f` is equal to `!iszero`.

For clarity, this commit also renames the helper method
_sparse_findnext()  to _sparse_findnextnz(), because now that the
predicate-less version doesn't exist anymore, the `nz` part isn't
implicit anymore either.

[1]: JuliaLang#23812

Thanks to @Sacha0 for the suggestion!

…types

This mostly means returning `zero(indtype(...))` instead of `0` in the
not-found case.  In addition, this commit replaces a few `== 0` checks
by `iszero()` to avoid unnecessary promotions. We could similarly
replace `+ 1` by `+ one(...)` but that becomes cumbersome very quickly.

This is needed in response to JuliaLang#24715.