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 .
In general any single method will never affect total code bloat much - it is simply a matter of big numbers. Generating 20 bodies instead of one is not that much of an impact when you have thousands of methods in the binary. Problem is that such overhead accumulates if one is overly careless and user can't fix it in any way. Template bloat for symbols is generally OK because those can be simply stripped from the binary, but I believe base frameworks/libraries should aim for minimal bloat of actual functions/methods to be able to scale nicely.

As for tooling - disassemble sample binary, measure the instruction size for single generated instance, multiply by estimated instance count in program. Can't imagine anything else tbh :(