Jets FFI

[sanket1729]

This PR aims to settle on a structure for automatically generated files for jets execution. As per the current design, we would need the files:

1. src/jet/init/core.rs
2. src/jet/init/elements.rs
3. simplicity-sys/src/c_jets/jets_wrapper.rs
4. simplicity-sys/src/c_jets/jets_ffi.rs

The tests here would fail because we are updating simplicity and a lot of jets are implemented. This should PR should pass once we have all the generated files. The goal is to get an ACK on the design.

[uncomputable]

I like the design. Adding c_jet_ptr to the Jet trait and default-implementing exec based on that is elegant because if I want then I can still implement everything in Rust by overriding exec. I have only skimmed the FFI, but clearly a lot of work has flown into it.

My only real remark is that we should separate the C jet pointers in simplicity-sys::c_jets::jets_wrapper into Core, Bitcoin and Elements. I get it, there is hardly a separation in the C library, but if we can separate the jets somehow, then this would avoid future confusion. Maybe this also answers the question how the jets are separated in the C library in the first place.

Besides that, maybe we can remove the unsafe code in Jet::exec and jet::elements::c_env? I don't know. According to @apoelstra , some unsafe code cannot be avoided. (I just read an article how UB breaks the entire binary, so I'm sensitive.)

[apoelstra]

Overall this looks great. I think we should break it apart into a couple smaller PRs. In particular the 1st and 3rd and 5th commits (update underlying Simplicity library; add cargo:rerun-if-changed=depend to build.rs; make Simplicity a non-dev-dependency could be pulled out and made into an uncontroversial PR, and reduce this one in size from 9 to 6 commits.

Then 479472b and 8de5acc and c33c3dc (which add C getters/setters for the structs; adds the actual jet FFI bindings; tweak the enviroment pointers) could be a separate PR which we could iterate on which does the actual FFI binding.

Then the remaining PRs would be a "actually use the FFI bindings in this library" PR, which initially we'd just use as a reference while we debated the other ones.

I've only briefly skimmed this. I have a few comments but my overall impression is that this PR is way too big to effectively review :).

[sanket1729]

@apoelstra. Cleaned some code, Fixed CI, and split into #48, #49, and #50

[apoelstra]

Thank you!! Let's close this one then.