ByteVec: immediate / remote immutable byte vectors + intrinsics.

I ended up going with @vtjnash's suggestion of representing this as an Int128 since that makes the code generation easier: you can cast the `Int128` to various vector types like `Uint8 x 8` or `Int x 2`, which are both handy for writing `bytevec_len` and `bytevec_ref` intrinsics.

The code generation is already pretty decent, e.g.:

	julia> s = Str("Hello")
	"Hello"

	julia> @code_native sizeof(s)
		.section	__TEXT,__text,regular,pure_instructions
	Filename: bytes.jl
	Source line: 64
		push	RBP
		mov	RBP, RSP
	Source line: 64
		mov	RAX, QWORD PTR [RDI + 8]
		vmovq	XMM0, QWORD PTR [RAX + 16]
		vmovq	XMM1, QWORD PTR [RAX + 8]
		vpunpcklqdq	XMM0, XMM1, XMM0 ## xmm0 = xmm1[0],xmm0[0]
		vpextrq	RAX, XMM0, 1
		neg	RAX
		vpextrb	ECX, XMM0, 15
		test	CL, CL
		cmovns	RAX, RCX
		pop	RBP
		ret

One area to investigate optimization is to try to make sure that the checks involved in loading a single byte can be hoisted out of loops *and* ideally, we want, instead of a loop with a branch inside of it a branch with a loop inside of each path, but that's a bit of a more tricky optimization than I think we're doing now. But with that code that iterates strings could really fly.

Next steps are to implement `bytevec_eq` and `bytevec_cmp` intrinsics. I know these aren't strictly necessary, but I suspect that the built-in versions can be made very efficient.
Thanks for pointing that out – this memory should never change and so should be decorated as `tbaa_const`, I believe, but @JeffBezanson may have something to say about that. One of the major goals of this rewrite is to much more heavily leverage the fact that strings are immutable.