Fix rescan/invalidate logic for Zk collections.

Fixes #317.

The previous coding did not mark Zk-backed collections as always needing
rescan. That is wrong to begin with -- the Zk code only put new tuples into
@storage, yet in non-rescan mode we might not examine @storage. Also, Zk
collections could change in arbitrary ways between ticks, so we can't always use
incremental mode safely.

We are now conservative and mark them as always needing rescan. We could perhaps
be more intelligent and only rescan when we notice that a previous tuple has
disappeared or changed, but for now this should at least produce the correct
behavior.

Note that in the #317 test case, inserting the "print" call is just another way
of triggering a rescan -- the use of "print" is an unsafe (side-effecting)
function, so we mark the scanned collection as needing a rescan.