Fix #19561 (sparse map/broadcast where the output eltype is not a concrete subtype of Number)

[Sacha0]

This pull request makes sparse map and broadcast work not only where the output eltype is a concrete subtype of Number providing zero. Specifically, this pull request handles the following cases: (1) The output eltype is concrete and either (1a) a subtype of Number providing zero or (1b) not a subtype of Number but supports comparison with 0. (2) The output eltype is abstract, but each output value either is (2a) of a subtype of Number providing zero or (2b) not of a subtype of Number but supports comparison with 0. Fixes #19561. Best!

[tkelman]

trying not to commit to a more public iszero yet?

[Sacha0]

trying not to commit to a more public iszero yet?

Trying to fix this bug without sparking... extensive, peripherally related design discussion :).

[kshyatt]

Is this mergeable?

[Sacha0]

Is this mergeable?

#17623 now introduces iszero functionality, so perhaps best to revise this pull request once #17623 merges (later this week). Thanks for the bump! :)

[Sacha0]

Will rebase on #17623 and #19690 if/when the latter clears. Best!

[Sacha0]

Rewritten with #17623 and #19690 in. (This pull request now performs zero-checking via a Base.SparseArrays.HigherOrderFns-internal function _iszero, which wraps Base.iszero from #17623 for Numbers and AbstractArrays but provides more permissive fallback behavior [such that this pull request still addresses the regression where the output eltype is e.g. Union{Float64,String}]). Best!

[Sacha0]

Having the @tkelman seal of approval, absent objections I plan to merge once AV clears. Best!

[Sacha0]

(AV x86_64 failure unrelated.)