Add serde impl for KeyPair

[elsirion]

The impl is added as a module instead of being a direct implementation since it uses the global context and users should be aware that.

[apoelstra]

ACK 1877e4d

It's a little unfortunate that serde depends on the global context, and also that deserialization is so very slow (involving a const-time EC mult), but I think this is alright. Or at least, hard to do better.

Would like at least one more ACK before mergign.

[elichai]

ACK 1877e4d
we can remove that feature gate next time we bump upstream, so even the precomp has signing context in it AFAIU

[apoelstra]

SGTM -- though bear in mind that it's not guaranteed for upstream to get rid of the context object for signing (or even make it "free") because of randomization. Though it may be cheap enough, next to the ec-mult, that we can just generate one inside the serde code..

[real-or-random]

we can remove that feature gate next time we bump upstream, so even the precomp has signing context in it AFAIU

The no_precomp context is not a signing context on upstream master. The reason is that you can't possibly randomize it, so it's always "less secure". Making this a "less secure" signing context is one of the things that needs to be talked about in upstream. So far, we refrained from doing so simply because this is an API change that can be talked about separately.

In fact, no_precomp (plus its clones) is the only remaining way to obtain a non-signing context.

I edited the upstream issue bitcoin-core/secp256k1#1065 to include this as a task.