Investigate feasability of bytecode backend

[lthls]

A number of optimisations are done in lambda/simplif.ml because we want them to apply to the bytecode compiler too.
It would make sense to use flambda instead to generate the bytecode.
Expected issues:

• Symbols do not exist in bytecode. Some of them can be compiled to constants, but not all of them (and most importantly, not closures)
• The code in Closure_conversion.close_c_call needs to use the correct primitive (and calling convention)
• Cmx files must not be emitted. They shouldn't be read either (because they would have been emitted for a native backend, so calling conventions for C primitives would be different), but it might be feasible to introduce a new file extension (.cmxo?) to hold the equivalent of cmx files for bytecode compilation, or to put it in an optional field of the cmo.

Although the Lambda language doesn't have any notion of closures, the bytecode language (described in bytecomp/instruct.ml) does, so separation of code IDs and closures is not a problem.