V3.9 - Fix "=" character in HttpPostRequestDecoder

Motivation
Issue #3004 shows that "=" character was not supported as it should in
the HttpPostRequestDecoder in form-data boundary.

Modifications:
Add 2 methods in StringUtil

split with maxParm argument: String split with max parts only (to prevent multiple '=' to
be source of extra split while not needed)
substringAfter: String part after delimiter (since first part is not needed)
Use those methods in HttpPostRequestDecoder. Change and the
HttpPostRequestDecoderTest to check using a boundary beginning with "=".

Results:
The fix implies more stability and fix the issue.
Fix build issues

Motivation:

When a the surefire plugin launches a new JVM, it does not specify any
limit on its maximum heap size.  In a machine with less RAM, this is a
problem because it often tries to consume too much RAM.

Modifications:

- Specify -Xmx256m option when running a test
- Fix a build failure due to the outdated APIviz

Result:

Higher build stability
Remove 'Content-Length' header from a chunked HTTP response

Related: #3076

Motivation:

When a user writes a chunked HTTP response with a Content-Length header,
the HttpContentEncoder should remove the Content-Length header because
the length of the encoded content is supposed to be different from the
original one.

Actually, HttpContentEncoder currently never touches the Content-Length
header when the response is chunked.

Modifications:

- Remove the Content-Length header when an HTTP response being encoded
  is chunked
- Add a test case

Result:

HttpContentEncoder sanitizes the Content-Length header properly.
[maven-release-plugin] prepare release netty-3.9.5.Final
[maven-release-plugin] prepare for next development iteration
Remove the unused .travis.yml
Rename from 'The Netty project' to 'Netty'

Motivation:

Sonar uses the project name in the pom.xml as the project name. (no pun
intended) 4.x and master uses 'Netty' as the project name, so we should
be consistent.

Modifications:

Rename the project from 'The Netty project' to 'Netty'

Result:

Prettier SonarQube result
Work around the Javadoc failure in JDK 8

Motivation:

Since JDK 1.8, javadoc has enabled a new feature called 'doclint', which
fails the build when javadoc has markup problems and more.

Modifications:

Do not fail the build until we fix our API documentation.

Result:

No more build failure because of malformed Javadoc
Backport the new methods and bug fixes in NetUtil

Related:

- 37a6f5ed5dd56284ec37e14e0554e912f84426a1

Motivation:

Minimize the backport cost by synchronizing NetUtil between 3.9 and 4.x

Modifications:

- Backport the bug fixes in NetUtil
- Backport the new IP address methods in NetUtil

Result:

- New useful methods in NetUtil
- Easier to backport the future bug fixes
Disable SSLv3 (POODLE)

Related: #3131

Motivation:

To prevent users from accidentally enabling SSLv3 and making their
services vulnerable to POODLE, disable SSLv3 when SSLEngine is
instantiated via SslContext.

Modification:

- Disable SSLv3 for JdkSslContext and OpenSslServerContext

Result:

Saner default set of protocols
SPDY: add support for pushed resources in SpdyHttpDecoder

Motivation:

The SPDY/3.1 spec does not adequate describe how to push resources
from the server. This was solidified in the HTTP/2 drafts by dividing
the push into two frames, a PushPromise containing the request,
followed by a Headers frame containing the response.

Modifications:

This commit modifies the SpdyHttpDecoder to support pushed resources
that are divided into multiple frames. The decoder will accept a
pushed SpdySynStreamFrame containing the request headers, followed by
a SpdyHeadersFrame containing the response headers.

Result:

The SpdyHttpDecoder will create an HttpRequest object followed by an
HttpResponse object when receiving pushed resources.
Backport ZlibTest and fix the bugs revealed

Related: #3107

Motivation:

ZlibEn/Decoder and JdkZlibEncoder in 3.9 do not have any unit tests.
Before applying any patches, we should backport the tests in 4.x so that
we can make sure we do not break anything.

Modification:

- Backport ZlibTest and its subtypes
  - Remove the test for automatic GZIP header detection because the
    ZlibDecoders in 3.9 do not have that feature
- Initialize JdkZlibEncoder.out and crc only when necessary for reduced
  memory footprint
- Fix the bugs in the ZlibEncoders where it fails to compress correctly
  when there are not enough room in the output buffer

Result:

We are more confident when we make changes in ZlibEncoder/Decoder
Bugs have been squashed
HTTP Content Encoder allow EmptyLastHttpContent

Related: #3107, origianlly written by @Scottmitch

Motiviation:
The HttpContentEncoder does not account for an EmptyLastHttpContent
being provides 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 trnasfer encoding is
chunked)

Modifications:

- HttpContentEncoder should not attempt to compress empty HttpContent
  objects.

Result:

HttpContentEncoder supports a EmptyLastHttpContent to terminate the
response.
Remove or de-prioritize RC4 from default cipher suites

Motivation:

RC4 is not a recommended cipher suite anymore, as the recent research
reveals, such as:

- http://www.isg.rhul.ac.uk/tls/

Modifications:

- Remove most RC4 cipher suites from the default cipher suites
- For backward compatibility, leave RC4-SHA, while de-prioritizing it

Result:

Potentially safer default
Use Triple DES in JdkSslContext cipher suite list.

Related:
- d6c3b3063fc367791dbddb76220110d864e5c5f8
- Original author: @grahamedgecombe

Motivation:

JdkSslContext used SSL_RSA_WITH_DES_CBC_SHA in its cipher suite list.
OpenSslServerContext used DES-CBC3-SHA in the same place in its cipher suite
list, which is equivalent to SSL_RSA_WITH_3DES_EDE_CBC_SHA.

This means the lists were out of sync. Furthermore, using
SSL_RSA_WITH_DES_CBC_SHA is not desirable as it uses DES, a weak cipher. Triple
DES should be used instead.

Modifications:

Replace SSL_RSA_WITH_DES_CBC_SHA with SSL_RSA_WITH_3DES_EDE_CBC_SHA in
JdkSslContext.

Result:

The JdkSslContext and OpenSslServerContext cipher suite lists are now in sync.
Triple DES is used instead of DES, which is stronger.