Bug 899757: Distinguish PR_ADDRESS_NOT_SUPPORTED_ERROR from other network failures. r=mayhemer

I broke out this this change on its own, because it seemed to require some care:
PR_ADDRESS_NOT_SUPPORTED_ERROR used to be lumped in with several other NSPR
error codes and reported as NS_ERROR_CONNECTION_REFUSED; and a dumb grep shows
that the NS_ERROR_ is widely checked for. Introducing the distinction might
require the new NS_ERROR_SOCKET_ADDRESS_NOT_SUPPORTED value to be checked for
everywhere that currently checks for NS_ERROR_CONNECTION_REFUSED.

But that seems unlikely to be necessary: first of all, it shouldn't really
be possible, via the XPCOM interface, to force this error path to occur at
present: the components' implementations are in complete control over which
socket address types get used. I also did a Try push with a call to
NS_ABORT if a PR_ADDRESS_NOT_SUPPORTED_ERROR ever flows through
ErrorAccordingToNSPR; there were no crashes.

But if that's so, then why introduce the new error code at all? A later
patch adds support for Unix-domain sockets, a type of socket address which
is *not* supported on non-Unix systems. In that case, a distinct error code
will help people diagnose problems quickly.
Bug 899757: Make nsServerSocket::InitWithAddress provide more detailed error results. r=mayhemer, r=ted

I looked through the NSPR socket creation functions that InitWithAddress
uses to see which errors they could return, and placed appropriate comments
in ErrorAccordingToNSPR.

The test coverage is not great; in particular, I wasn't able to find a way
to elicit "address in use" errors from Windows (although I could from
Linux); the web says that Windows is much more relaxed about binding
listening sockets than Unix derivatives. I'm interested in suggestions.
Bug 892114: Whitespace and spelling fixes encountered while working on Unix domain socket support. r=mayhemer
Bug 892114: Add support for Unix domain sockets to nsIServerSocket.idl and @mozilla.org/network/server-socket;1. r=mayhemer