introduction of CharBufs

see javadoc or PR for more information, but the short version is
- CharBufs are to char[]s as ByteBufs are to byte[]s
- more efficiency in exchange for less flexibility
- ideal use case is transient and frequently serialized strings
promote char[] semantics to primary issue

after running into it again several times while implementing
ascii sequence and researching bmp sequence, it has moved up
my hit list
about halfway through an 'any-utf' implementation

it uses an index caching system that I am far, far too proud of
to provide iteration-like performance through the non-iterating
char seq interface when it is being used to iterate chars.

it also works well for ascii-only strings, and should be pretty
okay for all but the worst possible cases -- which is pretty in
line with my degrading performance correlated with rarer cases
goal.
(mostly) functional release of read-only utf buf

it should work correctly if with imperfect performance for all
java strings that do not make use of utf 16 surrogate pairs.

the performance should be reasonable to good for most use cases,
but there is some low hanging fruit in the form of reverse scans
from the packed cache, hash iterations, probably some other cache
use case optimizations.

non-trivial tasks that remain: surrogate pair shimming, writable
impl, better iteration interface, prev mentioned low-hanging fruit,
and lots of performance testing
refactored tests and fixed two offby O(1) errors
support for surrogate pairs in read-onlys

we _do_ throw an exception if you try to subsequence a surrogate
pair in half. The only time that could possibly be intentional
is if you.. knew and were going.. to put.. them. back. no, it
doesn't make any sense. screw it.
guards on cache for large strings + misc fixes
byteIndex is now always an int bounded as a short
new packing scheme, more shortcuts, dry-er

microbenchmarks now show both byte array based implementations
(ascii-only and adaptive utf) as (sometimes by a factor of 3-4)
faster than Strings. This is a big improvement for the adaptive
version.

the byte buf utf implementation has decent performance -- edging out
Strings in a few cases.

all of these tests were done on strings that actually are ascii-only
though, and the non-ascii cases may benefit from a little love to
prevent a notable regression for the (although expected to be rare)
non-ascii cases.

memory footprint analysis shows that for small-ish strings, the
object overhead is pretty significant. Strategies for packing multiple
strings into one backing store may be beneficial if possible.

memory footprint analysis _also_ shows though that we have a free 4
bytes to use for something. This is because of memory aligning that
causes four bytes to be padded out anyway. So we could eg. cache
hashing for non-ascii versions or some other magic.
update documentation for index cache

since I went with the alt. implementation previously described
therein, it was potentially confusing to continue to refer it
as such
a few clean ups based on chris's feedback

- static helper methods in CharBufs cleaned up to reflect more
likely current usages
- byte array impls now also implement ReadableCharBuf, which has
had its ByteBufHolder implementation deferred to CharBuf and the
ByteBuf implementations.
- toByteBuf() method was added to ReadableCharBuf
continue to allow for efficient network/ disk operations
- documentation fixes
more clean up and ReadableCharBuf over CharSeq use

- moved and renamed the methods with _s
- added equals for byte impls that adhere to readable char buf's
contract
- more methods return ReadableCharBufs where possible
bump netty version
Merge branch 'benchmarks' into charbuf-manifesto
add license header
initial move of diagnostics from java-test
Merge branch 'benchmarks' into charbuf-manifesto
clean up charbuf benchmarks and fix types

- also set ByteBufs dependency to be propogated downstream
cleaned up jol example
add new, failing test + some doc cleanup + a TODO

CharSequence implementations are supposed to conform to a certain
toString() behavior, but since this is hard to enforce statically,
that behavior was not finished for some implementations. This test
checks for that and will have to be addressed.