Split `secp256k1_ec_pubkey_decompress` into in-place and copy variants #250

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.

@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.

ACK

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

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.

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

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).

Updated PR to just replace the function.

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.

Sure, changed :)

utACK.