Disallow empty arrays in maximum/minimum

[jishnub]

This mirrors the behavior of Arrays:
Currently:

julia> maximum(Fill(3, 0))
3

After this PR

julia> maximum(fill(3, 0))
ERROR: MethodError: reducing over an empty collection is not allowed; consider supplying `init` to the reducer

julia> maximum(Fill(3, 0))
ERROR: ArgumentError: reducing over an empty collection is not allowed; consider supplying `init` to the reducer

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.91%. Comparing base (6f61dc3) to head (d51c230).
⚠️ Report is 24 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #391   +/-   ##
=======================================
  Coverage   99.91%   99.91%           
=======================================
  Files           8        8           
  Lines        1147     1149    +2     
=======================================
+ Hits         1146     1148    +2     
  Misses          1        1           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dlfivefifty]

I don't actually think this is the right choice: an empty Fill kinda has an implied value which makes sense as an init in maximum

[jishnub]

I think it's important to respect the generic function's contract here, which would allow substituting a materialized array with a Fill easily and let us avoid hard-to-trace bugs. Also, the default value isn't used as an init in sum currently:

julia> f = Fill(4, 0)
0-element Fill{Int64}, with entry equal to 4

julia> sum(f)
0

julia> f' * f
0

It's best for such reductions to be consistent. maximum ideally shouldn't differ from a loop over the array.

[dlfivefifty]

We already violate the default in many other places, eg broadcast(x -> randn(), Fill(1, 100)).

Note that the places downstream that depend on this behaviour could possibly be fixed now that support is added for init. But I'm just not convinced there's any real benefit in changing the current behaviour