Implement different supervision policies for children that are being removed

[daniel-jodlos]

After remove_child action, the child remains fully supervised util it its process closes. Combined with crash groups, it may lead to unintuitive behavior in which a child triggers the crash group after calling remove_child: <child>.

One solution would be to introduce different policies for dealing with terminating children:

• orphan the child, ignoring how it terminates
• don't trigger the crash group, but still inform about the child crashing during termination (possibly it should be default?)
• Current, strict supervision

The behavior could be selected individually for each crash group in the spec

[mat-hek]

The behaviour could also be selected when removing a child

[daniel-jodlos]

Selecting the behavior when removing a child has an API problem. Because child id can be anything, we cannot use a tuple as action argument, this would make the call ambiguous.

I think we could define different actions for different policies (eg. remove_and_orphan_child, remove_child, supervised_remove_child) if we want to maintain compatibility with the current API.

[mat-hek]

Yup, orphan_child was what I thought of

[darthez]

Since we do not have a real live use for this issue we are not going to work on it as of now.