Backport of #735 to secp256k1-sys 0.10

[apoelstra]

This backports #735. I am PR'ing to the secp256k1-0.29.x branch because this will work and because it feels like unnecessary complication to try to create a secp256k1-sys-0.10.x branch, which might be "more correct" but would make our git tree harder to understand and maintain.

As in #735, this just deletes some dead code from secp256k1-sys/depend/secp256k1.

[Kixunil]

Do we want to ignore CI?

[apoelstra]

Yes. We only just started making an effort to fix CI to pin tooling last week. We don't want to try to backport all those changes.

[apoelstra]

Forgot to update the lockfiles (which in 0.29.x exist but are not checked in CI). Will get my local CI working on this before merging..

[apoelstra]

Note to self: needed to add

SECP_VENDOR_VERSION_CODE=0_10_0 \

to my local CI script to get it to pass, since by default it wants the symbols in secp-sys to match the version in Cargo.toml exactly. (But doing this would turn a non-breaking change into a breaking one, which is why I didn't.)

[Kixunil]

@apoelstra your CI fail made me realize we should do the same thing here as we do in bitcoinconsensus.

[apoelstra]

What in particular?

[Kixunil]

Version the API, not the library and put the upstream version into metadata instead.

[apoelstra]

Agreed. Though for purposes of this PR, we can't make such a change (as it'd be a breaking change to change our version format at all).

[Kixunil]

Well, we already are breaking our format here, but obviously I'm not NACKing this.

[apoelstra]

obviously I'm not NACKing this

Will you ACK it? :}

Fine if you don't want to, but there aren't a lot of maintainers on this repo and you're the one who appears to be active right now.

[Kixunil]

I already did and since GH didn't dismiss my review I haven't noticed the force push.

[apoelstra]

Tagged and published.