Enable 64-bit vectorization

Yes, the title is correct despite the innocent appearance of the diff. The patch represents `jl_array_t` more accurately in LLVM.  I implemented only the `data` and `length` fields since there was no clear benefit for representing the rest of the fields.

Julia's pointer casting was confusing stride computations in LLVM's vectorizer, so it mistook unit-stride load/store as high cost gather/scatter.  I had been wondering why the vectorizer was pricing a vector load at 51 clock cycles! I don't know why the problem did not exist for `Float32`, but it seemed some LLVM transform was  pushing casts around differently when the size of the array element type matched `sizeof(jl_value_t*)`. So maybe title is wrong for 32-bit targets :-)

Though we could try to get LLVM fixed, I think it's better for the code generator to "say what it means" and generate code closer to what Clang generates, since Clang is a prime client of LLVM. 

With LLVM 3.3, the 64-bit versions of the benchmarks in `test/perf/simd` ran 1.6x to 3.9x faster for me with the patch than without, using an Intel 4th Generation Core i7 processor ("Haswell").
Thanks.  In earlier lines, I see `jl_LLVMContext` is used sometimes, and `getGlobalContext` is used other times.   What's the difference?  Or is it just house-cleaning that hasn't been done yet?