Swallow EPIPE errors

 When thrown in a named pipe input channel - usually on pipe connection end. 

Under the current scheme, functions like `RoleEnvironment.getConfigurationSettings` take a callback which handles an error or a success. Except there's a problem - assuming you do handle the error (and don't kill the process because of it) the handler will get called TWICE. And the second time will be with the actual configuration data (as the first was passed the EPIPE shutdown that was thrown). 

While, for a lot of architectures, this simply means the EPIPE error gets logged or otherwise dealt with, then data handled, this is unacceptable when wrapping the API in promises, ala `Promise.denodify`. If I'm not mistaken, many of these callbacks are meant to be triggered once and considered done - not reused.

This might not be the way to change this to support this, but considering a `shutdown EPIPE` is always thrown on connection close (which `NamedPipeInputChannel` does automatically), it's probably not the worst idea.

Though, this may also be a good opportunity to ask how anyone feels about updating the API to work with promises correctly, rather than needing to wrap it.