fix #264 (bad movement masks), improve tests

Fixed silly movement mask bug.

This breaks the "legend of zokoban" test -- I made test failures now give *some* information (a state diff), but its usefulness & readability is limited for large states. Not sure precisely what's going on, it's likely that some part of Zokoban was experiencing the same bug. Hopefully it doesn't _rely_ on it.
I'd be all in favor of a modularized engine; maybe that means "state" or "level" are arguments that get passed around, or maybe we instantiate a Puzzlescript object which closes over all the previously global state and call `pzl.processInput()` on it or whatever.

I'm interested in using incremental 64 or 128-bit Zobrist hashing to reduce some overhead in the automated solver on the "analyzer" branch of my fork. It could also speed up the "did anything change" check in processInput or give more precise results for rule groups' "did anything change" result value.

What are you thinking of as a "fact" here? I'm leaning towards "bit X set at index Y" or "bit pattern X set at index Y". If we associate a random bit string with each such fact (for better spread and reduced chance of collisions), the former is the way to go or else we need `(2^objectCount)*n_tiles` different bit strings to hash in and hash out. It comes out to a few xors for each cell replacement, so the overhead doesn't seem too bad if the hash value is used more than once.

Phew. Anyway, if you want to mess with the cell replacement functions, restoreLevel (or whatever it's called), and the resolveMovement function to maintain these hashes, I'd certainly be interested in trying that out in my solver.

Right now I just rehash the whole map's ints after each turn (using a Jenkins one-at-a-time hash) and also take a similar hash of the map represented in run-length encoding; between those two hashes, the likelihood of collisions is very small. But I'd like to replace one or both with Zobrist hashing to avoid the overhead of calculating them. (I also take a hash of "the map minus players" for heuristic search purposes, but I could adapt the engine to maintain several Zobrist hashes instead of just the hypothetical one we're talking about.)

If you just want a plain old hash function for level states, I have that Jenkins hash function in my branch’s `js/engine.js`; the function is called `hashKey`. It also has a thing for shuffling certain objects to the end of the map, which I use to calculate “map modulo exact player positions”; you can cut that out to simplify it. It hashes a byte at a time because that’s how the original function was implemented and I don’t know enough about hash functions to change it and feel confident about that change.