Fix for Issue 16

[erosb]

The core problem was that TypeConverter, while converting request path parameters (or any other request parameters outside the body), was trying to figure out the parameter's probable type
using getSupposedType() which was fragile.

This "preemptive" speculation was necessary to understand if a literal value in the request like 2 should be parsed into a json string or a json number, before being passed to validation.
In other words the TypeConverter was attempting to convert these literals to their expected types before validating them by their json schemas.

This "speculation" was broken if the parameter's json schema didn't have a "type" keyword. That is actually the case when an enum (or const is used).

This PR fixes the problem by taking a very different approach on how the root problem "should we parse a path param like "2" as a string or a number" in a completely different way: now json-sKema has a lenient validation mode, which accepts number-formatted strings as numbers. Using the lenient mode while validating any request parameters outside the body makes the above
"speculation" with getSupposedType unnecessary.

Moreover, this was also a good opportunity to rework the validator.util.convert package to map the request parameter strings into JsonValue instances rather than jackson JsonNodes.
The mapping itself also became simpler.