Request with specific body

Aloha,

In peer.http.HttpRequest at the moment only parameters are treated and either send in the query string or the body depending on the set request method. This is hard coded.
However this leads to problems e.g. for DELETE requests, where a body is not explicitly forbidden by the corresponding RFC2616, but may not be send due to this behavior. Additionally if the body to be send is e.g. in JSON format it will break the query string.

The changes this pull request introduces will alter that behavior by adding a way to explicitly set a body. Any given parameters will then be added to the query string instead, regardless of the set method.

The new behavior will only be triggered if a content is set using setBody. 
If no content is set the behavior will not change, thus not breaking any existing code that relies on the previous/old behavior.

Side note: Additionally parameters now can be multidimensional arrays. The implementation will create a correct query string.

The old and new behavior is covered by still working unit tests and newly created, working unit tests.

The reason for this change was the need to send a REST DELETE request and hand over a TO holding information about the initiator of that REST request.



Additional information regarding the RFC can be found e.g. here:
http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request

Best regards,
Philipp

// edit:
The latest version uses/depends on the HeaderFactory of another Pull-Request.
The latest version does not yet include unittests for the new HttpRequestData and HttpRequestDataMulti. Those will be delivered with the next commit.

// edit2:
WIth the request and request data holding headers, there might be conflicts. Especially since RequestData has a method getHeaders(), but no way to set any, all request data related headers where/are set to the request itself, creating a conflict for the content-type in most cases with this implementation
The latest fix solves this by using the request headers rather the request data headers in a conflict scenario.