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.
Yes, I was thinking of writing a `bytevec_ref_char` intrinsic that does this efficiently and produces a character. These intrinsics are starting to be quite intense, but I think this is important and basic enough that it justifies a little insanity to get really great performance, even if that entails hand-coding LLVM code generation for it.