Fix reduce(vcat,...) type inference (#40277)

[dlfivefifty]

Fixes #40277

[thchr]

This may be a stupid question, but why does sum(map(length, V)) lead to succesful inference here while sum(length, V) doesn't (which I thought would be more idiomatic)? Same, question essentially for the original mapreduce(length, +, V)?

I realize V is a tuple, which I guess is a salient point, but I had imagined either of those variations would "work" the same way (e.g., they have the same performance and essentially the same native code in isolation; but I can vaguely appreciate that this in principle is separate from how they might interact with inference).

[JeffBezanson]

Not a stupid question at all; they should be the same. Maybe due to #35800.

[dlfivefifty]

I've had to work around quite a few type-inference issues and there are a number of rules of thumbs I've picked up:

1. map(f, v) is more reliable than broadcast(f, v)
2. sum(map(f, v)) is more reliable than mapreduce(f, +, v)
3. Sometimes it helps to write out a map or mapreduce explicitly: i.e. instead of mapreduce(f, +, v) one could write a function mapplus(v...) a la

mapplus() = 0
mapplus(x, y...) = f(x) + mapplus(x, y...)

[KristofferC]

I added an extra test that was reported from that issue

[simeonschaub]

Can we make this change just for V::Tuple and keep using mapreduce for V::AbstractVector, since in that case, it is probably beneficial to avoid the extra allocation?

[dlfivefifty]

Since vcat itself is allocating I don't think this will make any noticeable difference, but it's easy to add if there's a good argument for why it's still needed.