Simplify callback logic to returning raw coordinates

[elichai]

As requested by @real-or-random in #196 (comment)
this replaces the current logic where the callback is run by the C code to using a callback that just returns the raw coordinates and then the user's callback is executed in the rust side where panics are "fine" and no need to catch them or return an error.

Upsides:

1. Less code.
2. Less relying on rust internals which ease the bar of reviewing(less need to dive into rust's semantics)
3. No need to return a Result anymore.
4. 1 safe function no matter std or no-std.

Downsides:

1. Secrets are even at more places at the stack then they already are (right now we don't really try to mitigate against this, especially as long as Clear sensitive memory without getting optimized out bitcoin-core/secp256k1#636 isn't merged).
2. A bit less straight forward logic wise IMO.

FWIW, I tested both before and after this change with Miri on my c2rust branch(https://github.com/elichai/rust-secp256k1/tree/c2rust)
and they both pass.

[elichai]

FWIW, I tested both before and after this change with Miri on my c2rust branch(https://github.com/elichai/rust-secp256k1/tree/c2rust)
and they both pass.

You can run it yourself by doing:

rustup toolchain install nightly --allow-downgrade -c miri rust-src
cargo +nightly miri setup
git clone https://github.com/elichai/rust-secp256k1.git --branch c2rust
cd rust-secp256k1
cargo +nightly miri test --features=c2rust -- -- ecdh 

and then you can cherry-pick this commit and fix merge problems or apply this diff: https://gist.github.com/elichai/8414db8f410801d14b6479255e0f098f
and run cargo +nightly miri test --features=c2rust -- -- ecdh again

[apoelstra]

ACK. This is a million times easier to understand.

cc @real-or-random what do you think?

[real-or-random]

ACK

[real-or-random]

"via the type system" confused me for a minute. Yes, it's a valid scalar, otherwise it wouldn't have type SecretKey. But our code ensures this, not the type system. (Totally okay to merge like this, just wanted to note this.)

[apoelstra]

I think it's fair to say the "type system" is in charge of ensuring validity of data, if there is a type that the API prevents you from constructing in an invalid way.

[apoelstra]

Travis passed, except emscripten.

[elichai]

I did not realize this was merged :) we should remember this is a breaking change