Ramlwrap

A bug report where there is over-enthusiastic validation of content type - previous to this version, a request against an API with (for example) `application/json` would be validated as such:

* `Content-Type: application/json` would be valid
* `Content-Type: application/json; charset=UTF-8` would be invalid

Whilst arguably technically correct, we all agreed this was an unintentional over validation, and the change now allows for following directives on the Content-Type. There is no validation of the directives.

Many thanks to Rizzle93 for her patch and tests.

A minor release to allow Django 4.0 support (whilst also dropping Django 1.1) Many thanks to timharveyuk

Many thanks to Rizzle93 who has added some excellent additions to allow multiple content types on both up and down streams. Now validation won't fail if you want to define and allow those extra options.

Whilst most API's will result in a JSON or XML, or another UTF-8 based data language, sometimes we want to build API's which return a binary file. The team at CPI hit this issue recently, and the great jenniferagrimes has offered this minor patch to allow Ramlwrap to support it.

This is a non-breaking change and only needed if you have API's which are not returning JSON/XML etc.

Many thanks to timharveyuk and Emad88 who have provided fixes for a couple of edge cases:

* Handling empty status codes (e.g. a status code with no body or description) (55)
* Passing the Base URI into the documentation template so that it can be used to generate correct full urls

Tim Harvey has added code that allows the Documentation to handle multiple responses. 200's still go into the original response fields on the endpoint object, but there is now an array of response objects which allow you to produce better documentation for non-200 status's (204's, redirects, error codes etc).