[Epic] CEK machine optimizations

[effectfully]

This issue is for dumping all the plans regarding optimization of the CEK machine in a largely unstructured way.

[effectfully]

• we should try specializing the CEK machine at the restricting ExBudgetMode as it's the one that is used in production and having that code specialized may impact performance significantly
• Data.RandomAccessList.Class.indexOne returns a Maybe, a strict EvaluationResult instead would be more efficient
• GHC Core for UntypedPlutusCore.Evaluation.Machine.Cek.ExBudgetMode contains unnecessary packing and unpacking, for example 0# -> jump $j_sGXo r#_iGvO (I# r#_iGvO)
• UntypedPlutusCore.Evaluation.Machine.Cek.Internal for the Vector-based Case-expressions is unoptimized: it contains things like int2Word# followed by a word2Int# (i.e. a non-free no-op) and what looks like an unnecessary call to integerFromWord64#
• Is it possible to support join points in the CEK machine? The "Compiling without continuations" paper seems to say “yes”. If we had join points, we could’ve better implemented case-of-case (as per the paper) and possibly CSE
• currently we implement the stack in the CEK machine as a pure data structure, but it is conceivable that a mutable one would be faster, so we should try it out. Doesn’t seem to be too complicated, given that the CEK machine runs in the ST monad anyway.
• currently we use Vector in FrameCases. Would it be more efficient to use Array/SmallArray/custom data/manual loop unrolling?