consider separating Meter from per-crank limit

[warner]

Before #3308 landed, the only metering we did was to enforce a fixed per-crank CPU limit on any vat with the metered: flag set. This limits individual cranks from doing too much work (we use a fairly arbitrary limit of 100M computrons; for reference, evaluating the Treasury contract requires about 13.5M), but puts no limit on how many cranks can be run.

After #3308, this per-crank limit is applied to any vat which is bound to a Meter (the meter: option is set to a Meter instance), and not applied to non-Meter-bound vats. You get both, or neither. I added a special UnlimitedMeter, which never drains, to make it possible to emulate the previous metered: true behavior. I meant this as a bridge from the old code to the new approach: I changed all the places (Zoe, spawner) which created metered: true vats to use meter: unlimitedMeter instead. I expect most applications will replace those with a real (not unlimited) Meter, and will add code to track and refill that Meter as necessary.

In #3508 (comment)_ , @katelynsills suggested that we might separate out the control for per-crank limiting from the control that does long-term Meter tracking. It wouldn't be hard to do this, but I want to know that we have a use case for it first.

As mentioned on #3508, my half-considered opinion is that having a per-crank limit but not a Meter isn't really much of a limit: it protects against infinite loops but not infinite send-to-self cycles (with the assistance of a second vat, e.g. purse.getCurrentAmount()). So a vat in that state could consume effectively all of the CPU time.

The only use case I can think of for that mode would be the REPL, which is in a sort of intermediate state between "protect against accidents" but "trust that the code isn't malicious" / "if you break it, you get to keep both pieces". I added UnlimitedMeter to serve as a bridge from the old behavior to the new (charge account) one, and maybe the REPL will stay on it, but I figured real contract vats should not be allowed to use it.

cc @katelynsills @erights @dtribble