feat: notifications delay new request handling while running

[pnwamk]

Makes it so that the handling of a notification cannot be interrupted/interleaved with new commands/queries/notifications. This may be enough to fix GaloisInc/cryptol#1261

Tweaking the default state eviction policy to remove older requests automatically instead of reject new ones if the server is full (thus removing the need for scripts to call reset when connecting) may also be helpful.

[pnwamk]

This set of changes has two main consequences:

1. cryptol/saw python scripts should not have to reset the server each time they connect; new connections' states take precedence over older connections' states and the older states are auto-evicted when the server hits it's capacity. The capacity can be customized from the command line (--max-occupancy NUM) and the old behavior (i.e., not auto evicting) can be regained from the command line as well (--no-evict)
2. the "unknown state ID" errors should be a thing of the past because (a) now that we can skip resetting the server (which was the request occasionally "colliding" with the subsequent request on the server) and (b) several measures have been taken to ensure that even if people send notifications (such as a reset server command) they should not be interrupted and/or conflict with requests immediately following them. I have tested this locally (i.e., running a program that reliably caused the error previously in a loop) with the cryptol server and even with the reset_server=True flag (which we no longer need) no unknown state errors occurred.

[m-yac]

This looks awesome! I have a few questions, but they could just be due to me not having a full understanding of this codebase yet.

[atomb]

This looks good to me. I hope we don't need to keep the delay in the Python client for long, and can figure out how to remove the need on the server side, but I think it's okay to include for now.