Deprecate use of HTTP HEAD: instead use GET piggy-backing

The general approach now is to run an non-Range GET first (instead of
a separate step using HEAD) to both determine the Content-Length and
also to start downloading bytes in one shot, rather than waiting for a
response to HEAD before beginning any bulk data transfer.

This both eliminates some startup time that can compound when dealing
with smaller GETs and can avoid failure when working against a server
that does not support HTTP HEAD in a situation where htcat would
otherwise work fine.

Remove the benchmark section showing slower times on very small files,
because that caveat has now been removed, as the gap has been reduced
to about one tenth of what it was previously.  My measurements of the
same suggest about a 10ms difference between 'curl' and 'htcat', a
small enough difference that adding a whole table to the README is
probably not very illuminating versus its cognitive load.
Furnish new ball-park benchmark numbers

I now think I understand why the 10MB file test was *so* slow,
although it did not occur to me at the time: S3-Classic/US-Standard
may opt to home keys across the continent from one's instance, and
this does not seem to converge over time (e.g. through mirroring).
So, this can be re-cast as a "slow link" test.  It seems this can
happen if one uploads to S3 from a place geographically closer to
Seattle, unless one uses the s3-external-1 endpoint.  I uploaded the
test file from such a location.

Knowing this, I tried another small key made from within EC2 us-east.
This has become my new benchmark for "the very fast and very small"
pathological case.

Most mysterious is Amazon CloudFront: I cannot get it to perform well
with htcat at all, although it's offering excellent curl performance.
It's not even abundantly clear that slower processing of Range
requests is the whole story: I'm still baffled by the stark nature of
the results and a few other bizarre observations.