Improve guest TLB invalidation #721

Because we support rolling back/restoring a different snapshot within the same sandbox, we need to invalidate the guest TLB on occasion to ensure that no cached mappings that are no longer valid are around.

Currently, the guest itself executes tlb flush instructions on the entry path, which largely works for the rollback case, since that code itself has been present since the beginning. Unfortunately, it's not clear that this will always work as we move towards a model in which that code page may itself not always be at the same place. Ideally, the hypervisor would architecturally trigger a TLB flush itself, but it's unclear if APIs to do so are available on all platforms.

It would also be good to ensure that this forced TLB invalidation happens only on events (e.g. snapshot restore) where the host has in fact messed with the guest page tables. This would be much easier if the host controlled TLB invalidation.

Relatedly, in the future, for guests which do happen to share some amount of state (e.g. multiple different snapshots of a wasm engine loaded with a module, which all share the mappings for the wasm engine), it would be interesting to try to use ASIDs to avoid invalidating the common code page mappings when restoring a snapshot.