Issue #129 prompted me to look into how go-httpbin actually handles
incoming requests that specify an `Expect: 100-continue` header. Here we
add additional unit tests to explicitly codify the, uh, _expected_
behavior for those requests.

Note that the Go stdlib http client and server implementations have
automagical `Expect: 100-continue` handling, which means
these particular tests need to be written at a slightly lower level, by
directly writing to and reading from the underlying TCP connection.

Now, it may well be that the the moving parts (e.g. load balancers)
between a client and the instances of go-httpbin deployed at
https://httpbingo.org intervene and change this behavior, but these
tests give me some confidence that, at least when such requests are made
directly to go-httpbin itself, we are correctly handling them.

In testing out error handling after #135, I happened to stumble across
an unexpected panic for requests like `/status/1024` where the
user-provided status code is outside the legal bounds. So, here we take
a quick pass to ensure we're parsing and validating status codes the
same way everywhere.

Standardize on structured JSON error responses everywhere we can, with
only one exception where the error is a warning for humans to read.

Fixes #108 by adding a check to every request in the test suite to
ensure that errors are never served with a Content-Type that might
enable XSS or other vulnerabilities.

While we're at it, continue refining the test suite and further adopting
some of the testing helpers added in #131.

Cleans up inconsistent and incorrect content types for plain text, html,
JSON, and binary responses.

A set of test suite improvements following up on #131:
- Make sure we always fully consume and close response bodies, to allow
the shared HTTP client to reuse connections to the local test server
whenever possible
- Make order of arguments to equality assertions consistent, so failed
test output makes sense

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.

In the course of validating #125, we discovered that using the stdlib's
[`httptest.ResponseRecorder`][0] mechanism to drive the vast majority of
our unit tests led to some slight brokenness due to subtle differences
in the way those "simulated" requests are handled vs "real" requests to
a live HTTP server, as [explained in this comment][1].

That prompted me to do a big ass refactor of the entire test suite,
swapping httptest.ResponseRecorder for interacting with a live server
instance via [`httptest.Server`][2].

This should make the test suite more accurate and reliable in the long
run by ensuring that the vast majority of tests are making actual HTTP
requests and reading responses from the wire.

Note that updating these tests also uncovered a few minor bugs in
existing handler code, fixed in a separate commit for visibility.

P.S. I'm awfully sorry to anyone who tries to merge or rebase local test
changes after this refactor lands, that is goign to be a nightmare. If
you run into issues resolving conflicts, feel free to ping me and I can
try to help!

[0]: https://pkg.go.dev/net/http/httptest#ResponseRecorder
[1]: https://github.com/mccutchen/go-httpbin/pull/125#issuecomment-1596176645
[2]: https://pkg.go.dev/net/http/httptest#Server

Fixes #128

```console
# before: httpbingo lacks the "method" field but httpbin.org has it
$ curl -s https://httpbingo.org/anything | jq .method                                                                                                        9:31PM
null
$ curl -s https://httpbin.org/anything | jq .method
"GET"

# after: httpbingo has the method field!
$ curl -s http://0.0.0.0:8080/anything | jq .method
"GET"
```

This was mentioned in #6, but then not listed in #91

- I took the highly technical testing approach of adding a test for
`Method` anywhere in `handlers_test.go` that mentioned `Args`; do you
desire more tests? fewer tests?
- Anywhere else I should add this field that I didn't already?

For what it's worth, I discovered this when working on upgrading the
testing for our [httpsnippet
library](https://github.com/readmeio/httpsnippet); I wanted to use
`go-httpbin` but our tests expect the method field to be present in the
responses

Also, switch to URL-safe base64 instead of standard base64, for
compatibility with original httpbin.

Fixes #118.

This brings go-httpbin's behavior more in line with original httpbin.

Fixes #90.

Fixes #112.

BREAKING CHANGE: Requests for zero bytes now actually return zero bytes.
Requests for negative numbers of bytes are now rejected.

This can help debug misconfigurations, where it's useful to know whether a 404 response is due to a configuration issue in some upstream proxy (load balancer, gateway, etc) or due to an actual bad request to go-httpbin.

A few small improvements to the test suite:
- Ensure `/stream` and `/stream-bytes` endpoints actually use
`Transfer-Encoding: chunked`, instead of inferring/hoping based on
Content-Length header
- Explicitly test that `/drip` actually does sleep between writing
bytes, rather than inferring that it does based on entire response
duration

Make the error message when a forbidden destination is given to
`/redirect-to`, to help users better understand what allowed usage looks
like. Motivated by #103.

Before: 

```
$ curl http://localhost:8080/redirect-to?url=https://google.com
Forbidden redirect URL. Be careful with this link.
```

After:

```
$ curl http://localhost:8080/redirect-to?url=https://google.com
Forbidden redirect URL. Please be careful with this link.

Allowed redirect destinations:
- example.com
- example.org
```

This is a very small improvement to developer ergonomics.

The `/redirect-to` endpoint currently acts as an open redirect, which is
bad for any go-httpbin instance exposed to the public internet.

This allows configuring an allowlist of domains to which traffic can be
redirected.

Instead of serializing JSON to a temporary slice of bytes before writing
to the response, instead write directly to the response.

Also, pretty-print JSON responses for better readability (and to match
httpbin).

Note: With this change, we rely much more on the underlying net/http
server's implicit handling of the Content-Length header. One notable
side effect of this is that responses to HEAD requests no longer include
a Content-Length.

- Handle bodies for GET requests to the /anything endpoint
- Do not encode HTML tags in serialized JSON

We were not explicitly testing the behavior of some HTTP verb endpoints
like /put and /patch, because they currently share an underlying handler
with /post which is thoroughly tested.

The addition of the /anything endpoint in #83 made me realize a bit more
explicit test coverage would be good, so here we're landing a bit of a
refactoring of the test suite to generate tests for all of those
endpoints.

Along the way, we also improve compatibility with the original httpbin
implementation by tricking the stdlib net/http machinery into parsing
request bodies for DELETE requests.

This adds a new /hostname endpoint as originally proposed in #66. In
this implementation, it exposes a dummy hostname by default, and only
exposes the real hostname (via `os.Hostname()`) if the
`-use-real-hostname` flag is given on the command line.

- Set Content-Length

- Send status code before any delay

- Match default parameter values

* Added /base64/:value
* Added /base64/encode/:value
* Added /base64/decode/:value
* Create single TestBase64 with subtests
* Updated static/index.html with /base64 examples