Implement multipartI modifier

This branch implements multipart input to go along with the multipart output combinator.  I have tested it with curl and it seems to work fine.  There also looks to be no impact on my json GET/POST resources, so I don't think it breaks anything.  I did not test or assess the impact on rest-gen for docs/clients.

I have the following concerns about my implementation.  Not sure how problematic they might be.

* The multipart boundary is carried around in the MultipartFormat data contructor.  This makes Format no longer an Enum or a Bounded.  
* The BodyPart type is not re-exported from Rest.Dictionary.Combinators, so using mutlipartI requires importing Network.Multipart to get access to the type.  I don't know what the usual practice is for this kind of thing, so I left it alone.
* In this implementation, the body parts are all read as bytestrings and it is up to the handler to inspect headers in the BodyParts and parse the bytestrings as appropriate.  This requires either very complicated handling code or some kind of convention on the endpoint for significance and order of BodyParts (for instance, in my test code I check the number of body parts and throw UnsupportedFormat if the number is wrong).  I suspect there might be a smarter design that puts the header inspection/parsing into the backend code and out of the handler.

Thanks!  I am really loving the rest library.
This line is very unclear. I think it would be best to define 'unMultiPart' and use that to clear it up. We could even add that to the 'multipart' package, but adding it here would also be fine.

Also, this new line should be aligned with the ones above.