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

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 #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.