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 builtin versions can be made very efficient.
If you want a signed integer type that is big enough to hold the length of an arbitrary string (up to the factor of 2 lost by the sign bit), shouldn't this be `intptr_t` or `ptrdiff_t`?  The `long` type always scares me.