Cleanup argument coercion and validation

[bajtos]

A follow-up for #207.

• Move type coercion code from SharedMethod to contexts (HttpContext and friends)
• SharedMethod should only validate that argument values match argument types
• Reduce the number of cases that are coerced, return 400 Bad Request instead. Good example: array values coerced to a number/a string.
• Treat null value as empty, i.e. reject requests providing null value for a required argument.
• Refactor handling of "accepts" and "returns" type descriptors, create a class providing information like "isArrayType" or "isAnyType".

[bajtos]

I like the (re)design presented by @STRML in https://github.com/strongloop/strong-remoting/issues/312, especially the fact that we treat built-in and user-provided converters the same way.

I would like to push it a bit further so that user-provided converters can decide how to deal with sloppy coercion from url-encoded sources.

Here are few high-level cases that each converter has to support:

• Convert a value from JSON-encoded source, the type information is provided to some extent.
• Convert a value from url-encoded source, the value is always a string if set.
• For object-like types, support both nested keys ?filter[where]=1 and JSON encoding ?filter={"where":1}.

Additionally, I'd like to make it easy for for user-provided converters to run built-in sloppy conversion first before applying further transformation.

• converters for types backed by a number should be able to ask strong-remoting to sloppy coerce the url-encoded string value into number, thus applying the same set of validations as regular number types provide
• converters for types backed by object/array can ask strong-remoting to sloppy coerce the url-encoded string value (which may use JSON encoding under the hood) into object first.

Last but not least, the registry of converters should be scoped to RemoteObject instance, as opposed to current global singleton Dynamic. This is needed to support applications running multiple LoopBack app instances in the same process, where each app may provide different converter for the same type (model name). For backwards compatibility, we can fall back to global Dynamic for types that are not found in the local registry.

/cc @ritch @alexpit

[bajtos]

Most of the items were already done in #343.

Refactor handling of "accepts" and "returns" type descriptors, create a class providing information like "isArrayType" or "isAnyType".

This was not needed in the new implementation.