Update the status code stuff from RFC 2616 days.
Update the status code stuff from RFC 2616 days.

This means using RFC 7230 et al. instead of RFC 2616, and also taking
information from IANA’s [Hypertext Transfer Protocol (HTTP) Status Code
Registry](http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml),
most notably there the addition of links for each status code.

There are a handful of [breaking-change]s here:

- The status class 2xx `Success` is now `Successful`;
- 306 Switch Proxy, `SwitchProxy`, is partially removed, now becoming
  306 (Unused), `Code306`;
- 413 Request Entity Too Large, `RequestEntityTooLarge`, is now
  413 Payload Too Large, `PayloadTooLarge`;
- 414 Request-URI Too Long, `RequestUriTooLong`, is now
  414 URI Too Long, `UriTooLong`;
- 416 Requested Range Not Satisfiable, `RequestedRangeNotSatisfiable`,
  is now 416 Range Not Satisfiable, `RangeNotSatisfiable`;
- 419 Authentication Timeout, `AuthenticationTimeout`, is removed and so
  becomes `Code419`;
- 425 Unordered Collection, `UnorderedCollection`, is removed and so
  becomes `Code425`;
- 451 Unavailable For Legal Reasons, `UnavailableForLegalReasons`, is
  removed as the IETF draft it belonged to expired without replacement;

This brings the `StatusCode` enum in line with the registry, *except*
for the matter of 418 I'm a teapot, `ImATeapot`, which is inexplicably
not assigned in the register (I should try asking them about that), but
it’s such a crucial piece of Internet history and so forth that I can’t
bear to remove it.

For now at least, I’ve kept “(unregistered)” in all the doc comments of
the variants rather than switching it to “Unassigned” or similar as the
Status Code Registry would suggest. Smaller diff, and it’d be pretty
pointless anyway. But 306 remains a special case, “(Unused)”, as it is
in the Registry and RFC 7231, section 6.4.6.

Oh, and the matter about 1xx being invalid in HTTP/2 was reverted in one
of the drafts, 14 or so I think.

teepee/teepee,teepee/teepee