This commit changes the semantics of `BoundsError` so that it doesn't
capture arrays/tuples passed to its constructor.

The change wouldn't improve any performance by itself because the
`BoundsError` constructor is mostly called on error paths and thus
it is opaque to analyses/optimizers when compiling a caller context.
Rather it's supposed to be a building block for broadening the possibility
of certain memory optimizations in the future such as copy elision for
`ImmutableArray` construction and stack allocation of `Array`s, by
allowing us to assume the invariant that primitive indexing operations
into array/tuple indexing don't escape it so that our escape analyses
can achieve further accuracy.

Specifically, when `BoundsError` constructor will now compute the "summary"
of its `Array`/`Tuple` argument, rather than capturing it for the later
inspection. Assuming `Base.summary(x::Array)` or `Base.summary(x::Tuple)`
don't escape `x`, we can assume that `BoundsError` doesn't escape `x`.
This change won't appear as breaking in most cases since `showerror` will
print the exact same error message as before, but obviously this is
technically breaking since we can no longer access to the original
arrays/tuples by catching `BoundsError`.
I'd say this breaking semantic change would be still acceptable, since
I think it's enough if we can know size/type of arrays/tuples from
`BoundsError` in most cases.

As a last note, I didn't change the semantics for arbitrary user objects,
since we still don't have a good infrastructure to tell the compiler some
primitive assumptions/rules about user type objects anyway.