Netty Headers Class Restructure and Algorithm Updates

Motivation:
Headers within netty do not cleanly share a common class hierarchy.  As a result some header types support some operations
and don't support others.  The consolidation of the class hierarchy will allow for maintenance and scalability for new codecs.
The existing hierarchy also has a few short comings such as it is not clear when data conversions are happening.  This
could result unintentionally getting back a collection or iterator where a conversion on each entry must happen.

The current headers algorithm also prepends all elements which means to find the first element or return a collection
in insertion order often requires a complete traversal followed by a collections.reverse call.

Modifications:
-Provide a generic base class which provides all the implementation for headers in netty
-Provide an extension to this class which allows for name type conversions to happen (to accommodate legacy CharSequence to String conversions)
-Update the headers interface to clarify when conversions will happen.
-Update the headers data structure so that appends are done to avoid unnecessary iteration or collection reversal.

Result:
-More unified class hierarchy for headers in netty
-Improved headers data structure and algorithms
-headers API more clearly identify when conversions are required.
I like the idea but the current approach is to use the `add` (or `set`) method name with primitive type as the value (i.e. `Headers<T> add(T name, long value)`).  Is there a way to implement this suggestions and keep this approach?  For example I'm thinking of the following two approaches:

1. Rename all `add` and `set` which take primitives as a value type to represent their value type (i.e. change `add(T name, long value)` to `addLong(T name, long value)`).
2. Just add two new methods which are `addTimeMillis(T name, long value)` and `setTimeMillis(T name, long value)`.  This allows us to keep the `add(T name, primitivetype value)` signature pattern for primitives but then will not follow the `ValueConverter` scheme of `convertTypeName(...)`.

If we choose option 1, we would still need to do option 2 I guess ;)