Bulk upload of attachments

Attachments on Editions now have a toggle UI:

Choosing "Individual upload" (the default) gives you the normal ui.  You select files one by one and fill in the metadata as you go.  Then press save and the edition is created/updated with your files.

Choosing "Bulk upload" hides the normal ui, replacing it with a single zip file field.  You add a file to that then press the bulk upload button. This submits the form with the zipfile.  The zip file is unzipped and params are constructed to add the contents as attachments and we then continue on to save the edition.  We also add a flag to the edition that forces the save to fail and prompt the user to review the changes.  We take advantage of carrierwave's cache features to mean the unzipped files aren't lost and the user doesn't have to upload anything again as part of this review.  Unzipped files that match the filename of an existing attachment will replace the data on that attachment, unzipped files that don't match any existing attachments will create new attachments (and you have to fill in the metadata in the review).

Choosing "Bulk upload" ignores any params set on the "indiviudal upload" ui, and choosing "individual upload" ignores the zip file param from the "bulk upload" ui.

Happily, by just turning zip files into params and taking advantage of carrierwave's cache features we don't create a bunch of orphaned AttachmentData instances (which was the original plan for implementation).  But we do unzip things into /tmp/ - is this something we should worry about?