runsc container dies on one process getting OOM killed / runsc quits on SIGKILL to any child

Followup from: https://github.com/google/gvisor/issues/2520

It is possible for a guest process to get OOM killed by the host. When that happens, the guest process should die. Instead what happens is that the whole container quits, which I think is a bad behaviour.

To reproduce, first tune the host (not strictly required but helps):
```
swapoff -a
sysctl -w vm.overcommit_ratio=0
```
for the record, on the host:
```
$ sysctl -a|grep overc
vm.nr_overcommit_hugepages = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 0
```
Run a runsc workload without any special memory limits and request plenty of RAM:
```
$ docker run --runtime=runsc-debug --rm -it debian:buster /bin/bash
$ python3
>>> a = 'a' * 1024*1024*1024*1024
```
Behaviour:
- the docker dies
Expected behaviour:
- python process dies, docker and bash within remains stable

As a bonus point, I think this is a generic behaviour on how `gvisor` reacts to SIGKILL from outside. If we repeat the exercise and send `SIGKILL` from outside to the python3 process, again, the whole runtime will tear down.