When using S3 for storage, their data consistency model makes the
current behaviour of Attachment#reprocess! unreliable.

Apparently, Amazon can not guarantee that PUT's called after DELETE's
is actually executed in that order.

Hence, I propose preserving files, when doing a reprocces.

This ensures that multiline strings are properly matched in their
entirety.

Base64 encoded data-uris can contain newlines, make sure we handle
them correctly.

Content Type errors were incorrectly being set as an array on the base
attribute rather than being set individually as strings.

Copying attribute validation failures up to the root object breaks the
validate_attachment_presence_matcher when other paperclip validations
have failed.  This fixes this bug.

Also refactored to make the strategy hierarchy clearer

and memoize type_from_file_command

You can either specifiy :restricted_characters or you can define your
own :filename_cleaner object. This object needs to respond to #call and
takes the filename that will be cleaned. It should return the cleaned
filenme.

Return the default path when the attachment has no remote file

Using the ActiveRecord validations is smart in order to lessen load on
the project to develop our own validators, but it's problematic in that
calling `valid?` on the record fires off all the other validations --
including those on fields which may not be set yet because of
mass-assignment. This commit will "pre-validate" the attachment's fields
so that it doesn't process an invalid attachment, but it does so by
running its validations manually on assignment.

Refactor Paperclip::Attachment to eliminate code duplication between #extra_options_for and #extra_source_file_options_for

This commit makes this method move by default instead of copying, which
should make it perform significantly better with large files. It falls
back to the old semantics if the mv fails.