Solve #47: Use own Serializer/Deserializer for HTTP-Headers

[SvenBunge]

Instead of Json we use a combination of string-concatination and UrlEncode.
For example a Map or TPIC with this content:

final Map<String, String> context = new HashMap<String, String>();
context.put("Sven", "lovesTracEE");
context.put("Asterix says", "§$%&@/(");

is rendered to:
Asterix+says=%C2%A7%24%25%26%40%2F%28,Sven=lovesTracEE
The full TracEE-Header:
TPIC: Asterix+says=%C2%A7%24%25%26%40%2F%28,Sven=lovesTracEE

[danielwegener]

Looks good to me so far. In this turn, we could consider the case where multiple TPIC-HttpHeaders are set and their values are applied to the resulting map in the order of their occurance in the HTTP-Request. This would allow the case where "stupid" components like a HardwareLoadBalancer could add fields to the invocation context just by adding a constant header and without actually parsing, modifying and rendering an existing TPIC-Header.
This would change the signature from parse(String):Map[String,String] to parse(List[String]):Map[String,String] and break the contract of the TransportSerialization superclass. In this turn we could also get rid of the Abstract TransportSerialization class which is, again IIRC, kind of useless.

But since this feature does not break any backward compatibility, this could go into another feature request as well.

[SvenBunge]

I've added an additional commit to parse multiple headers instead of the first one only.
(I've deleted the TransportSerialization)

[danielwegener]

Looks good!

[coveralls]

Coverage decreased (-24.7%) to 57.19% when pulling e31937a on SvenBunge:httpHeader into b238c1c on tracee:master.