Split secp256k1_ec_pubkey_decompress into in-place and copy variants

[apoelstra]

Right now secp256k1_ec_pubkey_decompress takes an in/out pointer to
a public key and replaces the input key with its decompressed variant.
This forces users who store compressed keys in small (<65 byte) fixed
size buffers (for example, the Rust bindings do this) to explicitly
and wastefully copy their key to a larger buffer.

Add a variant secp256k1_ec_pubkey_decompress_copy which takes an
in-pointer and an out-pointer for the public key.

[apoelstra]

@gmaxwell suggested I check the rest of the API for cases like this; I did, it is the only one that takes an in/out pointer to a byte buffer.

[dcousens]

ACK

[sipa]

Just replace the old function.

[gmaxwell]

I'm largely ambivalent but I suggested otherwise because most people will not assume a writable parameter can alias.

[apoelstra]

My thoughts were the same as @gmaxwell's. For the sake of a cleaner API I think I lean toward just replacing the function, though.

If @gmaxwell ok's it I'll change the PR to do this.

[gmaxwell]

I certainly don't mind; just wanted sipa to be aware of that argument, if he wasn't in case it changed his thinking.

[ghost]

Looks good (Tested ACK), I'll update my JNI PR relative to this once the API is finalized here, too (FWIW I was having trouble the other day with this due to not realizing the buffer had to be large enough to hold the expanded pubkey if the buffer is != 65 bytes going in, this makes the (somewhat obvious) assumption more apparent).

[apoelstra]

Updated PR to just replace the function.

[gmaxwell]

One might wonder how one can decompress uninitialized memory. :) I think that part of the comment is a bit weird and you can probably drop it; in C I've never worried that my output needed to be initialized.

[apoelstra]

Sure, changed :)

[gmaxwell]

utACK.