Reduce processInput allocations

Includes my refactoring PRs #231, #232, #233, and #238. The commits of interest are probably just 8315e4c (to fix an unrelated minor editor bug) and 844852c. Reproducing the comment from the latter:

This especially targets short-lived allocations.
* Non-rigidbody games won't store rigidbody-related state backups.
  * Non-rigidbody games should therefore no longer allocate anything due to processInput except for undo backups.
* Games with again rules will still generate one backup per `again` which will be thrown away after processInput returns
  * In the future, this could be fixed by using a single scratchpad backup for again evaluation and providing a backupLevelInto() function.
  * It might also be possible to rephrase again slightly: "It can only trigger if something changed on this iteration through the rules", rather than "it can only trigger if something would change on a subsequent iteration through the rules". This would avoid duplicate calls to processInput (once with dontModify=true, once with dontModify=false) and reduce the number of required backups by 1 in the case where again rules are used.

The upshot of all this for automated solvers is a lot less frequent garbage collection churn, and user-facing speed improvements of around 20-30%. As for regular game play, I don't know that it will be especially noticeable except that it will use slightly less RAM or suffer fewer GC pauses—maybe this is good for realtime games?

Specifically, I changed `playerPositions` and `level.bannedGroups` to reuse the same storage for every frame, avoided storing rigidbody backups when no rigidbody rules are used, replaced some `concat([])` with `slice()` to avoid making temporary empty arrays, added a couple of new stored bitvecs for sound effect masks, avoided recreating new command queues, used `pop()` instead of `splice()` to remove the last backup, changed a couple `getCell()` calls to `getCellInto(0)`, and other little things like that.