REST enhancement #1.1: Refactoring for client side code generator

While I was working on implementing `@queryParam` / `@bodyParam` parameters (following #908), I was blocked by the client-side code generator which hardcoded [some stuff](https://github.com/rejectedsoftware/vibe.d/tree/master/source/vibe/web/rest.d#L366).

In addition, the usage of `Json` was a bit annoying, and blocking for the evolution of this module (while not on my priority list, I'd like to make serialization customizable).

Downsides:
- Potentially breaks code, but none that #908 did not already broke. If someone extended the client implementation, parameter change, so CT error. However, I think that this use case is rare and that some might be doing to mimic newly added functionalities (e.g., modifying the headers).
- Moar template: Obviously, `genQuery` / `genBody` introduce some more template. It is however not so important, as the code is small. On the REST example, file size went from 20178584 to 20193288 (Linux x86_64). This is an increase of 0.7%.

Upsides:
- Moar doc;
- Less symbols introduced inside the scope of the function;
- request now respects the `Content-Type` set by the user, if any;
- Reduce dependency to Json;
- More optimized code;
- Makes any addition that want the parameters at a specific place easy to implement !

Note:
There is a style update (first commit) and the refactoring itself (second). It's way better seen splitted :)

Usual ping to @Dicebot .
Actually, not so much. In the P.R. test I mentionned that I was also bothered by this, but the size for the example increased by a negligeable factor (0.7%). I think the reason is that the code generated is so small, it's basically a to!string.

There will only be one template generated per method, so I'm quite confident this change will not impact binary size negatively.

Do we have any tooling / methodology to investigate how a change will increase binary size, besides testing ?