Speed up IO work

Utilizing `IO.copy_stream` was a bit difficult to implement, so I split it into multiple commits. Detailed argumentation for each commit is in their description, so I will just summarize here.

When we're copying IOs, we want to do it in the fastest and most memory efficient way possible. `IO.copy_steam` does just that. I learned about it from a RubyTapas (series about implementing the `tail` UNIX command), and Avdi Grimm said that in his personal benchmark "it performs close to an order of magnitude faster" than manual `#read` & `#write`.

Utilizing `IO.copy_stream` requires us to use real IO objects, so we have to remove the loose requirements of just responding to 4 methods (`#eof?`, `#read`, `#close` and `#size`). We don't lose anything by this, because I can't imagine people not using real IO objects. That means we also have to simplify the S3 implementation, which I find positive.

If find the S3 simplification justified because files will almost always have to be processed before displaying, meaning that they will have to be downloaded first. This downloading is now much more efficient because of `IO.copy_stream`. We also get a bonus that instead of streaming the file we could just use `#send_file`, which enables us to assign filenames like the documentation suggests.

I know this is quite a bit, but these changes were all intertwined so that's why they're together. I know that this breaks any backend whose `#open` method doesn't return an IO object. Let me know what you think.
I removed it because we're not using using these methods directly anymore. So, my idea here was that we tell to users: "The object passed to `.upload` must be an IO object". And then the backend will raise an error if that requirement wasn't satisfied.

In `FileSystem` example, instead of investigating to what `IO.copy_stream` responds to, I find it much more natural to just let `IO.copy_stream` raise an error if it didn't receive a right kind of object (we saw now that it might only need to respond to `#read`). Before we used `IO.copy_stream`, we called `#read`/`#eof?`/`#close` inside the backend, and if one of those methods would be missing, then we would get exactly the same kind of error ("undefined method `#<name>` for <uplodable>") as the manual checking above, so I found this checking not needed.

In `S3` example, instead of checking for those 4 methods, we could just let aws-sdk handle the input validation (judging from the [source code](https://github.com/aws/aws-sdk-ruby/blob/master/lib/aws/s3/data_options.rb#L109-L128), it seems to do the validation really well). For example, then the "IO" could even be a `Pathname`, because aws-sdk (and also `IO.copy_stream`) supports it.

If people are using for example S3, and they want to find out what kind of "file" does it accept, I find it natural that they look at the aws-sdk documentation rather than Refile's. The same for other backends.