Retry failed downloads

HTTP GETs for downloads are retried up to 5 times. This includes both
the initial GET of a buildpack invocation (detect, compile, or
release), which doubles as an internet availability check, and
subsequent GETs when the internet has already been checked and is
deemed to be available.

The retry limits for the initial GET and the subsequent GETs are coded
as two distinct constants in case we want to make the values
diverge. However, I think it makes sense to keep them the same
because a user who got spurious internet unavailable behaviour
because of a transient error would probably be just as put out as a
user for whom a transiet error cropped up during a subsequent GET.

The downside of retrying the initial GET is that when the internet
really isn't available, it takes longer for the buildpack to realise.

This shouldn't be an issue unless the GET request takes a significant
time to fail, in which case the effect is to multiply the total such
delay per buildpack invocation by a factor of 5. Reducing the retry
limit for the initial GET would alleviate this somewhat at the risk of
not handling transient errors so well. A better solution, when the
delay is unacceptable, is for the user to fork the buildpack and
disable remote downloads in config/cache.yml.

[#57311364]
Merge 57311364-retry-failing-downloads to master

[Completes #57311364]