Str/length: cleaner definition of the bitmask for length computation
Str: branch-free UTF-8 decoding is competetive with current decode.

This is not that impressive since the current decoding is known to
be a bit slow, but not that if we use that same algorithm here it is
considerably slower. Thus, there's a chance that with more work on
other parts of the ByteVec implementation – most notably coaxing
LLVM to swap the here/there test with loop bodies – this version
could be more efficient and perhaps even competitive with the ASCII
version and faster than our current UTF-8 implementation, which may
let us use just a single basic string type for both UTF-8 and ASCII.