Use tbaa for heap-allocated immutables

This adds `tbaa_immut` metadata to loads/stores from/to heap-allocated immutables. I'm not entirely sure this is safe, since it is possible for a user to use `pointer_from_objref` and alter such immutables, but that would seem to go against the spirit of immutables and it's not possible for stack-allocated immutables in any case.

This addresses "hoist access to fields in immutable values" from #3440. It may not be the best we could possibly do, since the field accesses still can't be hoisted in a loop that creates a heap-allocated immutable and then accesses a constant field in a different heap-allocated immutable. OTOH, it's unlikely that the loads would be the overhead in such a loop, as opposed to the allocation.

On my system, this combined with #8827 is sufficient to make the benchmark from #8809 faster for ContiguousViews than Arrays with `@inbounds`. (It shouldn't be faster, though. I think this has to do with suboptimal behavior from the LLVM 3.3 loop vectorizer, since the benchmark is twice as fast on an array with LLVM SVN.) It gives a speedup without `@inbounds` but doesn't erase the gap. The IR with bounds checks is very similar; I think the remaining overhead must come from the fact that the bounds checks for ContiguousViews are based on the length of the whole array rather than the length of the view.