Replace HttpHeaders.Names/Values with HttpHeaderNames/Values

Related: 4ce994dd4fe58a03fa25b0911e5b3a2079b33692

Motivation:

In 4.1, we were not able to change the type of the HTTP header name and
value constants from String to AsciiString due to backward compatibility
reasons.

Instead of breaking backward compatibility in 4.1, we introduced new
types called HttpHeaderNames and HttpHeaderValues which provides the
AsciiString version of the constants, and then deprecated
HttpHeaders.Names/Values.

We should make the same changes while deleting the deprecated classes
activaly.

Modifications:

- Remove HttpHeaders.Names/Values and RtspHeaders
- Add HttpHeaderNames/Values and RtspHeaderNames/Values
  - Make HttpHeaderValues.WEBSOCKET lowercased because it's actually
    lowercased in all WebSocket versions but the oldest one
- Do not use AsciiString.equalsIgnoreCase(CharSeq, CharSeq) if one of
  the parameters are AsciiString
  - Avoid using AsciiString.toString() repetitively
    - Change the parameter type of some methods from String to
      CharSequence

Result:

A user who upgraded from 4.0 to 4.1 first and removed the references to
the deprecated classes and methods can easily upgrade from 4.1 to 5.0.
Remove non-standard header values from HttpHeaderValues

Motivation:

x-gzip and x-deflate are not standard header values, and thus should be
removed from HttpHeaderValues, which is meant to provide the standard
values only.

Modifications:

- Remove X_DEFLATE and X_GZIP from HttpHeaderValues
- Move X_DEFLATE and X_GZIP to HttpContentDecompressor and
  DelegatingDecompressorFrameListener
  - We have slight code duplication here, but it does less harm than
    having non-standard constant.

Result:

HttpHeaderValues contains only standard header values.
Remove CollectionUtils

Motivation:

CollectionUtils has only one method and it is used only in DefaultHeaders.

Modification:

Move CollectionUtils.equals() to DefaultHeaders and make it private

Result:

One less class to expose in our public API
HTTP/2 OutboundFlowControl negative window excpetion

Motivation:
The DefaultOutboundFlowController was attempting to write frames with a negative length.  This resulted in attempting to allocate a buffer of negative size and thus an exception.

Modifications:
- Don't allow DefaultOutboundFlowController to write negative length buffers.

Result:
No more negative length writes which resulted in IllegalArgumentExceptions.
HTTP/2 to HTTP/1 non-ascii headers reset stream

Motivation:
The HTTP/2 specification indicates that when converting from HTTP/2 to HTTP/1.x and non-ascii characters are detected that an error should be thrown.

Modifications:
- The ASCII validation is already done but the exception that is raised is not properly converted to a RST_STREAM error.

Result:
- If HTTP/2 to HTTP/1.x translation layer is in use and a non-ascii header is received then a RST_STREAM frame should be sent in response.
Keeping HTTP/2 HEADERS frames in-place WRT DATA frames.

Motivation:

Currently due to flow control, HEADERS frames can be written
out-of-order WRT DATA frames.

Modifications:

When data is written, we preserve the future as the lastWriteFuture in
the outbound flow controller.  The encoder then uses the lastWriteFuture
such that headers are only written after the lastWriteFuture completes.

Result:

HEADERS/DATA write order is correctly preserved.
Closure of stream with pending frames causes GO_AWAY.

Motivation:

The current logic in DefaultHttp2OutboundFlowController for handling the
case of a stream shutdown results in a Http2Exception (not a
Http2StreamException). This results in a GO_AWAY being sent for what
really could just be a stream-specific error.

Modifications:

Modified DefaultHttp2OutboundFlowController to set a stream exception
rather than a connection-wide exception.  Also using the error code of
INTERNAL_ERROR rather than STREAM_CLOSED, since it's more appropriate
for this case.

Result:

Should not be triggering GO_AWAY when a stream closes prematurely.
HTTP Content Encoder allow EmptyLastHttpContent

Motiviation:
The HttpContentEncoder does not account for a EmptyLastHttpContent being provided as input.  This is useful in situations where the client is unable to determine if the current content chunk is the last content chunk (i.e. a proxy forwarding content when transfer encoding is chunked).

Modifications:
- HttpContentEncoder should not attempt to compress empty HttpContent objects

Result:
HttpContentEncoder supports a EmptyLastHttpContent to terminate the response.
Add generic versions of PromiseAggregator and PromiseNotifier.

Motivation:

ChannelPromiseAggregator and ChannelPromiseNotifiers only allow
consumers to work with Channels as the result type. Generic versions
of these classes allow consumers to aggregate or broadcast the results
of an asynchronous execution with other result types.

Modifications:

Add PromiseAggregator and PromiseNotifier. Add unit tests for both.
Remove code in ChannelPromiseAggregator and ChannelPromiseNotifier and
modify them to extend the new base classes.

Result:

Consumers can now aggregate or broadcast the results of an asynchronous
execution with results types other than Channel.