Optimize out copying of buffer in eagerReader

Instead of supporting the generic io.Reader interface, support only
io.WriterTo and io.Closer.

Previous to this, copying memory was the biggest bottleneck not in
net/http.  Now, synchronization and newEagerReader is the bottleneck.
Boil down the general approach of htcat in the README
Fix crash bug: .Close on nil pointer

Closing an HTTP response body is not necessary when an error is
received.
Vertical whitespace
Do not close Body when a HTTP error is received

Fixes a nil-pointer dereference crash.  This is the same mistake as in
e68cbd61015af33a50950417b7460661710bb0d6.
Deprecate use of HTTP HEAD: instead using GET piggy-backing

The general approach is to run an non-Range GET 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.

Beyond squeezing out some startup time -- which definitely can add up
on small files in a loop -- this has the major advantage of degrading
more gracefully: HTTP endpoints that cannot support "Range", degrade
gracefully, and endpoints that do not support "HEAD" are no longer
problematic.