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.
I was referring to the `next` function for loops over the codepoints in the string, which advances by a variable number of bytes on each codepoint.  I was hoping that you could agressively load say 4 bytes into memory and do the decode step in a more efficient way.

I agree that the `length` function could be vectorized much more easily.