Make primitive.h functions indirect

[roconnor-blockstream]

The original plan here was to build different Simplicity primitives (e.g. Elements and Bitcoin), which are selected at link time.

However, we would like to link multiple sets of primitives into Haskell for testing purposes. This means we will need different names for the Bitcoin and Elements to bind them.

To support this we turn the primitive.h functions into callbacks for the various specific primitive implementations.

Various functions are rearranged to support the removal of primitive.h and make the pairing of .c file implementing .h header files more consistent. It should now be the case that each .c files implement exactly the declairations of one .h file.

[apoelstra]

ACK 1a4006c; successfully ran local tests; though without seeing the bitcoin code it is hard to tell what exactly needs to be pulled into callbacks

[roconnor-blockstream]

I pushed an update to my WIP bitcoin branch you can take a peek at. Notably simplicity_bitcoin_decodeJet and simplicity_elements_decodeJet are both used in the Haskell FFI as part of testing, and thus they need to have different names in order for them to link. You can sort of see part of this aspect in this PR in that Haskell/Tests/Simplicity/Elements/FFI/Primitive.hs has been updated to use the new simplicity_elements_decodeJet.

The old name for this function was simplicity_decodeJet and it was part of the interface where we "use link-time to change the Simplicity application from Elements, to Bitcoin, (to potentially alternative Simplicity applications)" idea. But if the function name is change to simplicity_elements_decodeJet to allow multiple applications to be linked simultaneously in Haskell and Rust bindings, then something has to be done about the old simplicity_decodeJet.

And that something is going to be using function pointers for simplicity_elements_decodeJet in some way, either by assigning them to some sort of const global variable (an alternative approach that I tried), or by fishing the function pointers through the call stack, this approach, which I'd argue is a bit better than using global variables.

[apoelstra]

Ok, perfect. So I understand the motivation here, and it's obvious that decodeJets needs to be different for bitcoin and elements. My confusion was that you're also splitting mallocBoundVars which doesn't obviously have a bitcoin/elements dependence. So I worry that there are other "nonobvious" cases.

[apoelstra]

Ok, out of band you told me that the "things that need to split" are "the things that were in primitives.h" which is straightforward enough.

[roconnor-blockstream]

Yep. mallocBoundVars also pre-allocates all types which are used in jets, which is why it is application dependent.

There might be a better design surrounding that bit of code, but this design had the best tradeoffs that I could think of at the time.