Allow incomplete downloads to be resumed even when server rejects HEAD requests

[smammy]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example. In order to write a test for this I'd have to refactor curl_download or (I guess) mock curl_output and curl and I don't know how to do that. Old behavior wasn't unit-tested either so I don't think it's a huge deal.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

Use GET rather than HEAD when checking for range support in curl_download.

• Some HTTP servers apparently support ranges but don't support HEAD.
• This is a more realistic check anyway since the actual download request
  will use GET (not HEAD).
• This fixes Downloads don't resume if server doesn't support HEAD requests #5420.

[MikeMcQuaid]

CC @reitermarkus for thoughts.

[smammy]

Although, honestly I don't understand what was wrong with the behavior before 0721271 where curl_download always tried --continue-at - and recovered from the error if the server didn't support partial content. (Most servers seem to these days, so the old pre-0721271 behavior would save us an HTTP request in the common case.) #4847 doesn't explain why the upfront check was added, but I assume there was some reason for it.

[reitermarkus]

I think the reason for the upfront check was that some servers which don't support ranges wouldn't actually fail with the appropriate error code.

[MikeMcQuaid]

Thanks so much for your first contribution! Without people like you submitting PRs we couldn't run this project. You rock, @smammy!