JSON validation based on Swagger Schema

[fizruk]

Closes #12.

This PR is incomplete, TODOs:

• validate object schemas;
• validate string regex patterns;
• add tests ensuring that ToSchema matches ToJSON;
• display better error messages;
• add documentation.

TODOs after #17 is merged:

• validate ParamSchema separately;
• add tests ensuring that ToParamSchema matches ToHttpApiData.

[fizruk]

So validation tests reveal two problems:

• schema for () is incomplete (it lacks necessary items schema, but it's unclear what it should be);
• validation of Maybe a schema is wrong, we should accept null there; but then how do we know which schemas allow nulls and which don't?

@dmjio any thoughts?

[fizruk]

This PR raises too many design questions so far:

• which validation library to use (validation, these or home-grown)?
• should we maybe reuse validation from hjsonschema (probably not since Swagger Schema is a bit different)?
• what should we do about ToSchema ()? some swagger spec validation tools accept our schema without items, so should we go against what's written in the spec and allow it?
• what should we do about Maybe a? should we always allow null (maybe with a warning)?

Since it is not critical to servant-swagger, I postpone this PR until after v1.0.

[fizruk]

Of the above the ToSchema () instance has been fixed recently with items: [] (in 4139a57).
This only works for Schema, not ParamSchema though.

[fizruk]

Going with home-grown validation. Not using hjsonschema.

The only problem so far is schema for Maybe a. However it is only a problem when it is not a property of an Swagger object (e.g. Haskell record fields are okay being Maybe).

I am going to finish this to include in 2.0 release.