ISSUE-44: move response classes to toplevel package
Add license
Update description of apidoc
Merge pull request #52 from gilt/enums

Add support for enums
Add initial support for object datatype
Add object support to ruby client
Remove option from error message
Add note on the quality of the clients
Update client
Update generated client
Update org created based on return type from new client
Clean up response codes, validation error
fix travis.yml
Rename object type to map. Make it a Map[String, Any] as default implementation
Validate defaults for Map and Boolean
Merge pull request #54 from gilt/issue-48

Support for generic objects (maps) of String -> Any
Remove InternalFieldType

 - we're back to a single field type for internal fields - and always
   a string. Just use a string so code will be simpler
 - Fixes #51
Merge pull request #58 from gilt/issue-51

Remove InternalFieldType
Update unit tests around apidoc api.json
Revert decision to use Map[String, Any] as map implementation.

 - Problem is we cannot guarantee JSON serialization for type Any resulting
   in compiler errors.
 - It is annoying to use something like Map[String, JsValue]...
 - Go back to Map[String, String] -> it is the responsibility of the caller
   when using maps to serialize to/from string.
 - This has the nice benefit of discouraging use of Map which is one of our
   goals with Apidoc (well defined APIs should have typed records, not maps),
   reserving the use of maps to where they make APIs more natural (e.g. true
   key value store APIs like Tags)
 - Acknowledge that this is a subpar implementation - there will be APIs we
   cannot support with this decision - but we expect those to be rare. In
   most cases we expect to be able to support APIs by defining more concrete
   model types.
 - In practice, this is a nice incentive for API designer as maps have the risk
   of making API less predictable to use.