support nested multipart, strict no-content parts CRLF and better part metadata resolution

[fmigneault]

Features and Fixes

• Given a part that has "no content" (None) (as if it was returned on its own by an HTTP 204 No Content response), MultipartEncoder will not incorrectly insert a second \r\n anymore. A parser that strictly interprets the amount of \r\n can distinguish a "no content" part from an "empty string" part, which can have different meanings depending on the embedded Content-Type (e.g.: a null vs "" for JSON).

• Fixes requests_toolbelt.multipart.decoder.ImproperBodyPartContentException: content does not contain CR-LF-CR-LF #352.
  Multipart decoder correctly understands a single \r\n used to separate the headers from the "no content" body. The resulting part returns None rather than "". A part still using CR-LF-CR-LF explicitly will enclose an empty string.

• Add a content_type parameter to __init__ allowing to override the default multipart/form-data that was hard-coded.

• Support nested multipart.
  Using the MultipartEncoder as file_pointer in the input fields of another MultipartEncoder will correctly nest the contents, with their respective boundaries. This can be used to form complex structures of multipart/mixed, multipart/alternate, multipart/related commonly used when combining various attachment representations.

• When headers are provided for one of the parts, ensure that any Content-Type, Content-Location or Content-Disposition explicitly provided in them are not overridden by the urllib3.fields.make_multipart step. This allows using other dispositions than form-data, such as attachment or inline as needed.

[fmigneault]

@sigmavirus24

Hi.
I would like to contribute these fixes and improvements for the multipart utilities.
Let me know if anything should be adjusted further.