Efficiently handle writing ( wrap(...) ) of CompositeByteBuf when using ...

...SslHandler

Motivation:

SslHandler.wrap(...) does a poor job when handling CompositeByteBuf as it always call ByteBuf.nioBuffer() which will do a memory copy when a CompositeByteBuf is used that is backed by multiple ByteBuf.

Modifications:

- Use SslEngine.wrap(ByteBuffer[]...) to allow wrap CompositeByteBuf in an efficient manner
- Reduce object allocation in unwrapNonAppData(...)

Result:

Performance improvement when a CompositeByteBuf is written and the SslHandler is in the ChannelPipeline.
This may be a bit specific for this use-case but I'm guessing the `nioBufferCount()` call is often used to compare against 1 (or any number).  Would it make sense to add an additional method to the `ByteBuf` interface that would be something like:

```java
/**
 * Uses the <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html">Comparable</a>
 * interface paradigm to compare the internal NIO buffer count to {@code value}.
 */
int nioBufferCountCompareTo(int value)
```

The goal would be to avoid the need to know the class hierarchy when algorithms behave differently for multiple buffers or single buffers while potentially reducing the overhead of the call to figure this out.

WDYT?