Move away from cycle count for resource consumption estimation

The processor currently uses cycle count as a means to estimate resource consumption. That is, the user can specify a maximum number of cycles (through `ExecutionOptions`) that the processor should execute the program for, after which an error is thrown.

The problem is that this is a poor estimator of both CPU time and memory consumption. For CPU time, a malicious user could submit a program containing e.g. `repeat.N hperm end` would consume *a lot* more CPU resources than e.g. `repeat.N add end`. For memory consumption, any instruction that adds elements to the advice provider or write a lot to VM memory will consume a lot of prover memory (i.e. RAM) than e.g. `repeat.N add end`.

As part of this issue we should clearly identify the requirements that we were using cycle count to fulfill (e.g. CPU or memory consumption), and design an appropriate alternative, if any in this repo. For example, it could be that running the prover in a cgroup-bounded sub-process is the solution to both of the above requirements, and the actual processor doesn't need to keep track of anything related to those.