The `Status` enum only supports a portion of the response codes defined
by RFC 9110.  If the server returned a response code other than one of
the ones supported by the `Status` enum, the code previously threw away
the value.  This updates the code to also store the code as an integer,
so that users can handle other values.

I considered simply changing the `Unknown` variant to use
`Unknown(u16)`, but avoided it for now since this would break backwards
compatibility, and would also prevent using `status as u16` to convert
`Status` values to integers.

This replaces the `Status::Unknown` variant with a `Status::Other(n)`
variant that can be used to represent arbitrary status codes.  RFC 9110
defines a number of status codes that aren't currently specified as enum
variants, and servers may return other arbitrary codes.  This change
allows `Status` to represent any arbitrary code, rather than collapsing
unknown codes to a single value.

This does break backwards compatibility, as the `Status` variant can no
longer be trivial converted to a u16 (and it now requires more space to
store).  This also results in having more than one way to represent some
status codes.  e.g., `Status::Ok` and `Status::Other(200)` are both
treated as equal now.

This changes the Response `status` field from the existing `Status` enum
to a new `StatusCode(u16)` type.  This allows arbitrary code values to
be reported, including ones beyond the limited set represented by the
`Status` enum.

This is a breaking API change.  For one common conversion case,
Code using `match request.status {...}` to match against `Status` enum
values will need to be changed to `match request.status.into() {...}`