Improve witness output of simc (e.g. output hex)

[apoelstra]

There are a few problems with simc right now:

1. If you pass in a program it will compile it; if you pass in a program and a witness it will also typecheck the witness and then output an encoding of that. The impression the user gets is that we're "compiling" the witness somehow but actually we're just checking and re-encoding it.
2. The witness is output in a base64 encoding. It should be hex, so that it's visually distinct from the program (and also witness data is reasonably likely to be byte-aligned, unlike programs, so hex is a nice encoding).
3. The output is on stdout but it's not machine-readable unless you pass the --json flag.

I propose:

1. We default to JSON output; an object with three fields compiled_program, missing_witnesses, witness.
2. We output a map of missing witnesses and their types (so users know what's needed and this will also help make .wit files, especially while Witness files should not require explicit type annotations #177 is unfixed). Otherwise the missing_witnesses field is omitted.
3. If all witnesses are provided we output the complete witness in hex. Otherwise we output the field as null.

[schoen]

Maybe this is a type theory question but I was thinking of all of the data in the .wit file as collectively a single witness (thinking about witnesses in proofs, it is collectively the existential example that shows that the predicate is satisfiable). So I'm just confused about the plural there. I would think of them as "missing witness elements" or "missing witness data elements" or "missing witness fields" or something.

[schoen]

I do want to see JSON used in the output of simc more routinely as I already had a bug where I was getting the compiled program with tail -1 and the output format changed to add another blank line at the end, so my shell script was then receiving a completely empty program in every case. Now it's updated to sed '1d; 3,$d' (another option is sed -n 2p) which looks pretty ugly and fragile compared to a jq expression.

[apoelstra]

Yes, conceptually it's all one single witness, but in the code there are multiple witness bindings with distinct names, and the "one single witness" is a product of all these which decomposes into the named objects cleanly.