evicting local vats could be expensive

[dckc]

Describe the bug

The LRU policy from #2848 applies to all vats, including local vats. Paging a local vat out and in is likely to be expensive and should be avoided.

As @warner notes, our defaults are probably generous enough to avoid evicting any vat, so it's unlikely to be observable any time soon.

To Reproduce

Steps to reproduce the behavior:

1. reduce maxVatsOnline to something like 7
2. run agoric start
3. run ps ax | grep xsnap
4. see that there are fewer than 7 XS vats running, because some got evicted to make way for local vats

Expected behavior

local vats don't get considered for swapping out (eviction).

[dckc]

This is a performance issue but not correctness, IIUC.

[warner]

Another reason to deprioritize this is that we only have one local vat (comms), and it doesn't use a transcript anyways, so loading it back in is pretty cheap.

OTOH I don't think we've ever experienced it being evicted, so I'm not even sure we can have confidence that it would get paged back in correctly. But @dckc 's STR should exercise that pretty easily. So one task here is to just reproduce that and make sure comms still works afterwards. If that's true, we can probably put this off until we enable the creation of more vats (MN-2?)

[dckc]

we only have one local vat (comms), and it doesn't use a transcript

Nice! That addresses this issue, to my satisfaction.

I don't have any reason to believe that comms doesn't survive being swapped out, but if it does not, that seems like a separate issue (though I suppose morphing this one into it works for me).