HTTP/2 Decompress Flow Control

Motivation:
The current decompression frame listener currently opts-out of application level flow control. The application should still be able to control flow control even if decompression is in use.

Modifications:
- DecompressorFrameListener will maintain how many compressed bytes, decompressed bytes, and processed by the listener bytes.  A ratio will be used to translate these values into application level flow control amount.

Result:
HTTP/2 decompressor delegates the application level flow control to the listener processing the decompressed data.
@nmittler - Hum I agree with you about the decompression being optional and in general seems like a good idea to isolate the optional elements but here are some concerns:
1) Extra map for every stream is additional overhead/memory that may not be used.
2) Makes the interface less intuitive for using the "optional" features provided by the codec.  If we key the map by a string or class type then the users have to know which class or string to use.  This is another layer of indirection and level of understanding into the implementation of codec details. to use these features.  We would have to take care to avoid overlap in keys between codec "optional" features and application features.

Is there a good way to mitigate these concerns, or do you feel they are not significant in the grand scheme?