A compound literal within a global lambda or block is still within

A compound literal within a global lambda or block is still within
the body of a function for the purposes of computing its storage
duration and deciding whether its initializer must be constant.

There are a number of problems in our current treatment of compound
literals.  C specifies that a compound literal yields an l-value
referring to an object with either static or automatic storage
duration, depending on where it was written; in the latter case,
the literal object has a lifetime tied to the enclosing scope (much
like an ObjC block), not the enclosing full-expression.  To get these
semantics fully correct in our current design, we would need to
collect compound literals on the ExprWithCleanups, just like we do
with ObjC blocks; we would probably also want to identify literals
like we do with materialized temporaries.  But it gets stranger;
GCC adds compound literals to C++ as an extension, but makes them
r-values, which are generally assumed to have temporary storage
duration.  Ignoring destructor ordering, the difference only matters
if the object's address escapes the full-expression, which for an
r-value can only happen with reference binding (which extends
temporaries) or array-to-pointer decay (which does not).  GCC then
attempts to lock down on array-to-pointer decay in ad hoc ways.
Arguably a far superior language solution for C++ (and perhaps even
array r-values in C, which can occur in other ways) would be to
propagate lifetime extension through array-to-pointer decay, so
that initializing a pointer object to a decayed r-value array
extends the lifetime of the complete object containing the array.
But this would be a major change in semantics which arguably ought
to be blessed by the committee(s).

Anyway, I'm not fixing any of that in this patch; I did try, but
it got out of hand.

Fixes rdar://28949016.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285643 91177308-0d34-0410-b5e6-96231b3b80d8