Define extrema using mapreduce; support init

[tkf]

Like #36188, but now for extrema.

This patch also switches the implementation of extrema to use mapreduce. It improves the performance even for simple arrays:

julia> @btime extrema($(randn(1000)));
  5.502 μs (0 allocations: 0 bytes)      # before (1.6.0-DEV.220)
  2.988 μs (0 allocations: 0 bytes)      # after (7b0e72efc8f7fbf2c0bd5d30a8b6e2e22288547f)

The improvement is much more drastic when mixing it with iterator transforms because it hits the transducer path.

julia> @btime extrema($(Iterators.flatten(((0, 1, 2), randn(1000)))));
  195.393 μs (5489 allocations: 133.03 KiB)  # before (1.6.0-DEV.220)
  3.469 μs (0 allocations: 0 bytes)          # after (7b0e72efc8f7fbf2c0bd5d30a8b6e2e22288547f)

Of course, for arrays, we might want to use the same unrolling trick as in minimum/maximum. But that's tracked by #31442 and can be done later. I think this PR would be a good generic fallback that is useful as a baseline for #31442.

One thing not so great about this PR is that I had to copy the old iterate-only extrema implementation to compiler.jl as apparently it is required for bootstrap. I think it might be nice to separate out a very minimal portion of reduce.jl so that it can be included from the compiler. But that's a bit too large refactoring to do in this PR.

[nalimilan]

Just a few superficial comments.

[nalimilan]

Aren't these still useful?

[tkf]

mapreduce has a specialization for Number:

julia/base/reduce.jl

Line 419 in 5142abf

mapreduce(f, op, a::Number) = mapreduce_first(f, op, a)

So, I think the compiler will generate the equivalent machine code.

[nalimilan]

Cool. Maybe worth checking just in case?

[timholy]

Looks great! Needing a special version in compiler isn't so bad, IMO.

[simeonschaub]

Bump. Looks like this just needs to be rebased.

[Moelf]

bump, hitting extrema slower than (maximum, minimum) again recently

[DilumAluthge]

@tkf The CI failures seem related to the contents of the PR.

[tkf]

This passed the tests for SparseArrays locally but I noticed that it's not hitting the right method. Unfortunately, the build process ignores missing name on import and happy define HigherOrderFns._extrema_itr

Profile  ──────────  0.286842 seconds
WARNING: could not import Base._extrema_itr into HigherOrderFns
SparseArrays  ─────  2.713728 seconds

We need some fix in SparseArrays to make it reasonably correct and practically OK. (100% correctness is impossible with the current facility in Base because SparseArrays seem to want to assume max and min are commutative. We need to revive #36424 for this.)

[tkf]

#43604 took care of this