Specifying a different filename; Not storing the ContentDisposition header.

[mikedilger]

Currently there are two places where name exists within the files array: (1) the first string in the pair, and (2) the name in the ContentDisposition header. filename OTOH is only in the ContentDisposition header (and thus more difficult to access for readers).

Additionally, when writing out a FormData, the filename for a FilePart is taken from the path of that part. But the consumer of the library might want to specify a different filename than the actual one on disk.

I suggest fixing these problems in the following way:

1. Store a filename in the FilePart (this change is required in mime-multipart)
2. Consider the first string in the pair the canonical name, and the FilePart.filename the canonical filename.
3. When reading, interpret and strip out the ContentDisposition header. When writing, ignore any ContentDisposition header and instead compose one from the canonical data.