improve life with large tuples a little

[carnaval]

I put the cutoff mentioned in #15702 in there.
tuple _apply inlining was unlimited.
Otherwise it's mostly trying to avoid llvm scalarizing load/store of large aggregates. Instead it uses the memcpy intrinsics so it is lowered to a function call when the size exceeds some thresold.
It's not very systematic, I'm just going through examples I see with catastrophic IR explosion while throwing random large tuples around.
Without this patch, just passing a large tuple through to the constructor of a type like

immutable C
x :: NTuple{N,Int}
end

generates an amount IR linear wrt the size of the tuple.

I'm hoping this won't prevent optimizations on small sizes (we may want to add our own thresold for that if it happens). Anyway, I trust llvm more to break up a small memcpy than merge a lot of loads.

[carnaval]

just for fun, before :

$ time (./julia -e 'code_native(i->i, (NTuple{2000,Int},))' | wc -l)
4010

real    0m25.366s
user    0m25.289s
sys 0m0.285s

after

$ time (./julia -e 'code_native(i->i, (NTuple{2000,Int},))' | wc -l)
20

real    0m0.497s
user    0m0.497s
sys 0m0.210s

[vtjnash]

should use data_pointer() instead of v.V (in case v is a constant)

[vtjnash]

this doesn't matter either then (since you already checked for isconstant)