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 part has the only real problem I saw. You no longer split on '/', but you still pattern match on "application" and "image", which is never going to work, since those cases previously matched any content type starting with "application/" or "image/", but now they only match those literal strings.

I think a good solution would be to use the content type header parser from the 'multipart' package (which we're already using for the multipart stuff). That will give an actual data type containing the type, subtype and parameters.