Re-factoring download and extraction to enable hash based caching

The `remote_file` helper supports sending headers with checksum (and timestamp) to prevent downloading files if they are present already and matching the one to be downloaded. By not moving the downloaded zip files before extracting we can let this optimisation kick in. With an initial chef run there's no difference. However if you want to update a server by running recipes, it accelerates the process if you don't have to download the files again, but only if they are matching. I disabled the modification date based caching, since it might occur that the download is aborted leaving a damaged file with newer timestamp in place.
If you feel that this change backward compatibility, I'm happy to change the default value for the attribute controlling this behaviour to keep downloading the file even if there's a match.
Not exactly. At least as far as I understand you need to set `use_conditional_get` to `true` to enable the two other settings. As the documentation says for both `use_etag` and `use_last_modified`:

> To use this setting, `use_conditional_get` must also be set to `true`

So basically `use_conditional_get` enables or disables any caching and the other two flags enables specific caching methods.

That being said `use_conditional_get` is `true` by default so actually your proposed solution would do the same for now but I find it less clear why :)