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").
Currently there's no functional difference because we only use one context. I imagine with the threading work progressing we may at some point have more than one, so `jl_LLVMContext` is preferred.