Establish logging policy in cases of error and propagation of actual exceptions

**Issue by [jrudolph](https://github.com/jrudolph)**
_Thursday Aug 21, 2014 at 12:03 GMT_
_Originally opened as https://github.com/akka/akka/issues/15714_

---

E.g. in `HttpManager` we react differently on network errors caused by `Http.Connect` and `Http.Bind` commands:
- an error during `Http.Connect` is DEBUG-logged and then it's reported to the commander containing the remote address in question
- an error during `Http.Bind` is WARNING-logged and the singleton `BindFailedException` is reported to the commander

In both cases, neither the actual exception nor the message are reported back to the commander. This means it isn't possible for the commander to actually take responsibility for handling or reporting the error and thus it's easy to get into the old Java double logging anti-pattern.

I would propose a scheme where errors/exceptions are generally reported to the commander including the underlying message and if they are logged then only with DEBUG-level, to let the commander decide what to do with them.

It's probably not too useful to also send the stacktraces/original exceptions around, but there should be at least some way to log the stacktraces somewhere before they are discarded for debugging purposes.

/cc @sirthias

Start by inspecting HttpManager's handling of Http.Connect and Http.Bind errors, including how each command reports failures to its commander. Compare the current DEBUG and WARNING logging paths and determine how the underlying message and exception should be propagated. Done means the policy is agreed and consistently applied, with a defined way to preserve stack traces for debugging.

Written by the indexing model from the issue text.