Fix manually specified response schema names for same request, in OpenAPI 3

Thanks to @WonSik36 reporting #173 and fixing it with #174 !

OpenAPI 3 generator

Before, when manually specifying the schemata for responses with different content types, for the same request (same path, method and response status code), only the first schema name would have been referenced for all responses. This is now fixed to use the correct schema reference/name for the respective response.

Auto-generated schemata and schema names were unaffected.

Fix schema of path parameters in OpenAPI 3

Before, all path parameters were considered type string in the generated OpenAPI 3 spec.
Now, the actual type from the Spring Restdocs ParameterDescriptor is taken into account, see #168 and #171 for details.

Thanks to @alexisparis for the report!

Publish to Maven Central

• Publish to Maven Central instead of Bintray
• Maintenance release without behavior changes

Fix JSON Schema for required properties of type 'object'

Thanks to @beltram for fixing #138 with #155 !

Publish gradle plugin

3rd attempt with proper configuration of Gradle plugins portal credentials via environment variables (for TravisCI).

Publish gradle plugin, 2nd attempt

...with slightly changed TravisCI config.

Publish gradle plugin

No changes, just a separate tag/release to test publishing to gradle plugins portal.

Special thanks to @chadlwilson for providing the PR + lots of patience!

Deterministic snippet names and content-type parameters

• If multiple examples for the same request (same HTTP method, path and content type) are provided, the common snippet ID is now generated in a deterministic fashion, see #141 for details
• Add support for content-type parameters thanks to @CalamarBicefalo , see #142

Bump swagger-core version to fix YAML serialization of HTTP response status codes

Fix #139

Fix OpenAPI 2.0 + 3.0 generation considering application/x-www-form-urlencoded request bodies

Thanks to @afronski fixing #113 , restdocs-api-spec now properly supports application/x-www-form-urlencoded request bodies:

• Spring ParameterDescriptors may be used to document request fields
• Form data fields are now correctly rendered for OpenAPI 2.0 and 3.0 (see https://swagger.io/docs/specification/2-0/describing-parameters/#form-parameters and https://swagger.io/docs/specification/describing-request-body/ respectively)
• The schema derived from form data requests should now be correct for OpenAPI 3.0