fix: implement nil-safe Context methods on typhon.Request

[craigfe]

While downstreaming a new slog feature to Monzo's internal monorepo, I discovered that the empty typhon.Request value panics when the various context.Context methods are called on it:

typhon.Request{}.Value("foo") // panics

This happens because typhon.Request embeds context.Context, and so the zero value of typhon.Request has a typed nil context. This PR adds wrappers for the context.Context methods that behave like context.Background() on the empty typhon.Request value instead.

This is arguably not a bug: users of the library are expected to use either typhon.NewRequest or typhon.NewRawRequest to construct request values, these functions explicitly handle the nil context case, and the library makes no promises about the validity of the zero value.

Either way, we already have unit tests in our internal monorepo that build typhon.Request values manually and with the current typhon.Request implementation those tests are unstable: introducing a new call to one of the context.Context methods in a library (as I did in monzo/slog#22), can indirectly cause consumers of that library to panic. It's not difficult to add wrapper methods that work correctly for the empty typhon.Request value, so that's exactly what this PR does.

[craigfe]

Fly-by change: the minimum supported version in go.mod is already 1.19, and I've introduced a use of any that causes this library to fail to compile on 1.17.

[EddShaw]

I think there may be references to 1.17 and 1.18 elsewhere, breaking CI 🙈

[EddShaw]

Hmm, no. Not sure why CI is blocked on actions that no longer exist. 🤔

[EddShaw]

Nice!

[EddShaw]

I think we might need someone with repo permissions to fix branch protection rules.