Version 3.9 of proposal to change the TrafficShapingHandlers

Motivation:
Several issues were shown by various ticket (#2900 #2956).
Also propose a similar improvement on writability user management than from #3036.
And finally add a mixte handler, both for Global and Channels, with
the advantages of being uniquely created and using less memory and
less shaping.

Issue #2900
When a huge amount of data are written, the current behavior of the
TrafficShaping handler is to limit the delay to 15s, whatever the delay
the previous write has. This is wrong, and when a huge amount of writes
are done in a short time, the traffic is not correctly shapened.

Moreover, there is a high risk of OOM if one is not using in his/her own
handler for instance ChannelFuture.addListener() to handle the write
bufferisation in the TrafficShapingHandler.

This version includes a proposal for "user-defined writability" capability added to the channel,
where writability could be managed, using isWritable() only from user handler side.

ChannelInterestChanged is also managed in order to provide compatibility
with other handlers as for instance ChunkedInput.

The "bandwidth" compute on write is only on "acquired" write orders, not
on "real" write orders, which is wrong from statistic point of view.

Issue #2956
When using GlobalTrafficShaping, every write (and read) were
synchronized, thus leading to a drop of performance.
ChannelTrafficShaping is not touched by this issue since synchronzed is
then correct (handler is per channel, so the synchronized).

Modifications:
The current write delay computation takes into account the previous
write delay and time to check is the 15s delay (maxTime) is really
exceeded or not (using last scheduled write time). The algorithm is
simplified and in the same time more accurate.

This proposal handles the channelInterestChanged(), filtering the
events. This allows in some extent the compatibility with code using
natively channelInterestChanged().
Moreover it proposed to port partially the "user-defined writability" as
proposed in 4.X.

When the real write occurs, the statistics are update accordingly on a
new attribute (getRealWriteThroughput()).

To limit the synchronisations, all synchronized on
GlobalTrafficShapingHandler on submitWrite were removed. They are
replaced with a lock per channel (since synchronization is still needed
to prevent unordered write per channel), as in the sendAllValid method
for the very same reason.
Also all synchronized on TrafficCounter on read/writeTimeToWait() are
removed as they are unnecessary since already locked before by the
caller.
Still the creation and remove operations on lock per channel (PerChannel
object) are synchronized to prevent concurrency issue on this critical
part, but then limited using a ConcurrentHashMap.

Add a Mixte GlobalChannelTrafficShapingHandler which allows to use only one
handler for mixing Global and Channel TSH. I enables to save more memory and
tries to optimize the traffic among various channels.

Result:
The traffic shaping is more stable, even with a huge number of writes in
short time by taking into consideration last scheduled write time.

The traffic shaping is more compatible with code as ChunkedWriteHandler,
adding a "user-defined writability".

The statistics are more valuable (asked write vs real write).

An example is shown in the Discard example (example/discard), and
in particular how a user handler might managed the write to prevent OOM:

- using the ctx.getChannel().isWritable()
- using channelInterestChanged() to continue writing

The Global TrafficShapingHandler should now have less "global"
synchronization, hoping to the minimum, but still per Channel as needed.

Adding fix to preserve backward compatibilty

The GlobalChannel TrafficShapingHandler allows to have only one handler for all channels while still offering per channel in addition to global traffic shaping.