Reorganize NettyBufferProvider, NettyByteBuf and improve docs

[stIncMale]

I noticed a few things that are worth changing while working on the gRPC POC:

• NettyBufferProvider is production code, but is used only in a single test class.
• NettyByteBuf is package-access in an API package, bit in the POC I need access to it from a different package, so had to move it as public into an internal package.
• NettyByteBuf stores a reference to the proxied buffer in the heap memory but does not retain the proxied buffer. At the very least that should be documented.

[jyemin]

The ByteBuf abstraction is ... not good. It's something I've wanted to look at for a while but there hasn't been a good reason to mess with it.

[stIncMale]

I don't currently have an opinion on either our ByteBuf, or the Java SE one, or the one in the Netty API. But I understand why our own ByteBuf was introduced (to abstract over the Java SE API and Netty API), and I read in "Netty in action" why io.netty.buffer.ByteBuf was introduced instead of using java.nio.ByteBuffer (it's impossible to extend java.nio.ByteBuffer, which makes it impossible to implement a composite buffer or add reference counting).