move to byte based automata

[BurntSushi]

A prerequisite to a faster regex engine, and a DFA (see #66) is compiling UTF-8 decoding into the regex automaton. The reason why this is necessary, especially for a DFA, is so state transitions can proceed a byte-at-a-time and can therefore avoid large character maps in each state transition. We can preserve the invariant that all match boundaries returned are on UTF-8 code unit sequence boundaries by virtue of the fact that all regex automatons exclusively match valid UTF-8 encodings.

This is also a prerequisite to providing byte-based regexes that can match on a &[u8] instead of requiring a &str. See #85.

There are a few tricky components to this:

1. Translating an arbitrary Unicode codepoint range to a sequence of non-overlapping byte-based character classes. This is done already in the utf8_ranges crate.
2. Using said byte based character classes in the compiler. I've written a proof of concept, but the automata generated are squeamishly large for anything non-trivial.
3. Being diligent about supporting zero-width assertions that are Unicode aware. Fortunately, this crate only has one: word boundaries. (I think this should be somewhat straight-forward to do in the NFA and backtracking engines, but is hard to do well in a DFA.)

[BurntSushi]

This is proving to be quite tricky. I do have this working in my branch (including reducing the UTF-8 automata by reusing common suffixes), but it has introduced some weird problems.

Byte based automata are considerably slower when used in the NFA or backtracking engines. For example, matching a \pL goes from a binary search over Unicode codepoints to executing a regex program that is a couple thousand instructions long. This is an unacceptable performance regression IMO, so we'll need to support matching on both codepoints and bytes.

I did this by simply adding a Bytes variant to the instruction set, but this has a number of downsides:

1. A regex program with both a Bytes op and a Char/Ranges op is invalid, but this invariant is maintained at runtime. It would be nicer to enforce this invariant in the type system, but it seems tricky to do that while permitting the NFA/backtracking engines to match on either codepoints or bytes. It seems like the instruction codes might need to be put behind a trait, but it isn't clear what the interface should be yet.
2. A codepoint based program requires more memory per instruction and a byte based program requires many more instructions. This is bad because the byte based program ends up paying the overhead for codepoint programs, which is exacerbated by the increased number of states.

Since there are a few unknowns, I'm going to mush on to building the DFA before submitting a PR. Perhaps the right way to make instructions polymorphic will emerge from that...

[BurntSushi]

Done in 2aa1727