'NamedPipe' should be more robust

## Brief description

When the server side of a `NamedPipe` destructs it's endpoint, it can lead to a termination of the process using the client side.

It should behave more like a `UnixDomainSocket` where the server side can close a socket but the client side can still try to access it. In the worst case this will lead to a runtime error which can be handled gracefully.

## Detailed information

On destruction, the server side `NamedPipe` destroys the `NamedPipeData` which will lead to the client side user of the `NamedPipe` accessing an invalid object. Instead of destruction the `NamedPipeData`unconditionally, it could be marked for destruction. This could be done with an atomic (compare) exchange on a state variable, e.g.

```cpp
enum class State {
READY,
IN_USE,
DESTRUCTION,
};
```

On construction the state variable will be set to `READY`.

When a client opens the `NamedPipe`, the state will be set to `IN_USE` by a compare and swap operation with `READY` being the expected state.

On destruction two scenarios need to be taken care of
1. The server side destroys the `NamedPipe`
- a simple atomic exchange is sufficient
- the server sets the state to `DESTRUCTION`
- if the old value is `READY`, it can be destructed
- if the old value is `IN_USE`, the client need to destroy the `NamedPipe`
2. The client side destroys the `NamedPipe`
- since it is not the owner, it needs to do a compare and swap operation with `READY` as new state
- the expected state is `IN_USE`
- if the CAS failed and the actual state is `DESTRUCTION`, the client needs to destroy the `NamedPipeData`