CharBufs

there are a lot of details in the javadoc (particularly of CharBuf, AsciiSequence, and BmpSequence), but to illustrate my point, I will just describe a common data flow for a single character string. For emphasis, and because it is common enough to be reasonable, we'll assume it consists of standard ascii characters.

1. stored on disk in a worker's hydra tree as a UTF-8 byte array
2. read into a large byte[] by a bdb lookup operation
3. deserialized into a string by a query search thread and put into the tree cache. The cacheKeys have all kinds of logic for being represented as both Strings and byte[]s, and frequently pay the memory cost for both.
4. as a string it is now twice (or more due to String overhead) as large as it has to be, and probably went through several byte/char [] copies to get there
5. collected by a search thread and put into a bundle without ever so much as looking at the String.
6. serialized with the rest of the bundle and put back into a UTF-8 byte array. The serialization process assumes the worst and allocates a byte[] three times larger than needed; afterwards it realizes its mistake and reallocates another, smaller byte[].
7. arrives on the query master and is promptly deserialized yet again back into a String object.
8. sits around for a while wasting heap space
9. gets passed along to the output -- once again without being substantially manipulated.
10. yet again turned back into a UTF-8 byte array with the triple-size allocation and so on. Except this time it is while holding the query-wide op processor lock so it is blocking all the other threads.
11. multiplied by 100 million bundles with 2-3 or more string fields, and yet all the while the 'String' version could have been described as
```for (byte b : bytes) {
    (char) b;
}```

For some 'real' numbers, take a look at JsonBundleEncoder's jsonEncode(String s) method (in hydra). It is a method that is only used to make sure Strings are safely JSON formatted. Its naive implementation that looks reasonable actually causes it to be up to 20-40% slower than other output formats. That is just from 1-3 wasteful array manipulations (toCharArray copies the underlying char[] from the String because String doesn't trust you and byte[]s are too primitive to enforce read-only semantics; the StringBuilder is sometimes under-sized and has to redouble and reallocate; the sb.toString() call at the end always creates a new char[] array).

That said, this PR might need a couple more things before it is really ready.
- at least a few tests for AsciiSequence
- one of the implementations described in BmpSequence (which is itself abstract)

On the other hand, it will take a little while for various downstream apis to switch from Strings to the more general CharSequence (where possible), and AsciiSequence should by itself be usable for a non-trivial number of cases -- eg. constants and previously serialized values with page/ column block level flags.