Remove use of functors for sparse matrices and vectors

[KristofferC]

One step towards #15692. cc @timholy

[KristofferC]

Did some spot benchmarks:

triu! using #11685

# Master
julia> @time triu!(B);
  0.039143 seconds (4 allocations: 160 bytes)


# PR
julia> @time triu!(B);
  0.039338 seconds (5 allocations: 176 bytes)

sparse using #10694 (comment)

#Master
2.532434 seconds (27 allocations: 322.724 MB, 3.15% gc time)

#PR
2.347069 seconds (27 allocations: 322.724 MB, 3.80% gc time)

Enough for me...

[nalimilan]

You can remove one of the duplicate symbols here.

[KristofferC]

Good point, updated.

[KristofferC]

I only ran the sparse tests locally but this seems to break something with a type promotion test for broadcasting in test/arrayops.jl

[KristofferC]

Ok, reverting back to

(.*)(A::AbstractArray, B::AbstractArray) = broadcast_zpreserving(MulFun(), A, B)

should fix it. That is a pretty odd place to have a method definition for .* between all AbstractArrays...

[timholy]

If you're eager to eliminate this one too, you could presumably define a broadcast_zpreserving(f::Function, ...) and then have deprecated fallbacks like broadcast(::MulFun, ...) = broadcast_zpreserving(*, ...).

[KristofferC]

Not sure I am that eager :P. Although, talking about deprecations.. does all of this need deprecations since some people might have written code that uses functors to call for example sparse?

[timholy]

If exported functions allow a functor input (I haven't checked), then presumably it needs a deprecation. Non-exported functions are at-your-own risk, so don't need one.

In terms of just deprecations, an easier path might be to deprecate just Base.MulFun() itself, and have it generate *. Then you don't need to write any deprecations for any functions that accept functor inputs. So one option is to let this PR sit until some nice person helps out with the overall task.

[KristofferC]

AppVeyor timed out.

Sparse used to allow Union{Func, Function} as the combine function. Letting this sit is ok by me.

[vtjnash]

it would be better not to use ::Function in a signature, now that everything it callable, that distinction can be a bit fuzzy

[KristofferC]

Subsumed by #15804