This started with me wading into the `/drip` endpoint to add
`Server-Timing` trailers as suggested in
https://github.com/mccutchen/go-httpbin/issues/72.

In making those changes, I discovered that the standard golang net/http
server we're building on only supports sending trailers when the
response is written using `Content-Encoding: chunked`. Initially, I
thought it would be reasonable for this endpoint, which is designed to
stream writes to the client, to switch over to a chunked response, but
upon further consideration I don't think that's a good idea. So I'll
defer adding trailers to some later work.

But, in thinking this through (and fighting with the unit tests already
in place for drip), I realized that the `/drip` endpoint had room for
improvement, if we think about it as an endpoint _designed to let
clients test their behavior when an HTTP server is responding very
slowly_.

So, we ended up with these changes:

Initial delay semantics:
- Originally, `/drip` would immediately write the desired status code
and then wait for the initial delay (if any).
- Here we update that so that it waits for the initial delay before
writing anything to the response, to better simulate a server that is
just very slow to respond at all.

Incremental write timings:
- Switch over to a ticker to more accurately pace the incremental writes
across the requested duration
- Stop sleeping after the final byte is written (should not affect
clients, but avoids wasting server resources)

Worth noting that I now believe it's important that this endpoint
**not** switch over to chunked content encoding, because it is useful to
maintain and endpoint that simulates a server very slowly writing a
"normal" HTTP response.