Network Stack Reset limitations

We recently merged the network stack reset as part of https://github.com/CHERIoT-Platform/network-stack/pull/27.

Let us use this issue to keep track of the limitations of the reset:

- [x] The TCP/IP stack **cannot currently recover from a crash due to a stack overflow in the TCP/IP compartment**.
This is due to a limitation of the implementation of the switcher, which cannot trigger the error handler on stack overflow. We should make it possible for the error handler to run on stack overflow.
- [ ] A small set of **globals called *reset-critical* outlive resets and/or are necessary for the reset**.
We assume that this data has not been corrupted. This data is correspondingly annotated in the source code. We should address this with an inner compartment.
- [ ] We assume that the **control-flow of threads in the compartment has not been altered**.
Given that we have spatial and temporal memory safety, this should be a relatively sane assumption? We can revisit later - for now there is no plan to address this.
- [ ] Upon reset, **we do not close TCP connections**.
This leads remote servers to send us retransmissions which, in the case of several consecutive resets, can result in flooding. Ideally we should enable the reset code to send TCP RST packets to close outstanding TCP connections during the network stack reset.