support new TCPSocket API; revert to nsIProcess to fix regression

The primary purpose of this changeset is to support the new TCPSocket API and implementation ([bug 831107](https://bugzilla.mozilla.org/show_bug.cgi?id=831107)), which landed on mozilla-central last Friday and broke all consumers of the old API.

But the changeset has to do more than simply update API calls, because the implementation also changed in two important ways:
* Due to buffering in the new implementation, it isn't possible to reuse ArrayBuffer objects to send multiple packets, as mutations of buffers you previously sent will modify the data you previously sent.
* Due to [bug 865652](https://bugzilla.mozilla.org/show_bug.cgi?id=865652), you can't use offset/length arguments to send portions of buffers.

The latter issue will get fixed, but the former issue is an inherent limitation in the new implementation and must be observed. So this changeset creates a new buffer for each packet it sends.

Along the way, it also improves logging in a couple ways:
* It routes all packets through the *socksend* function, so all of them are logged.
* The *socksend* function logs packets by converting them to two representations: a binary "hexdump" and its ASCII equivalent. The latter is done using a TextDecoder, but the charset of the decoder was the default (UTF-8), which treats some bytes as part of multi-byte encodings and decodes them to a single character, which can make the array of characters get out of sync with the array bytes they represent. So I changed the charset to Windows-1252, which is also ASCII-compatible but is a single-byte encoding.

Finally, this changeset reverts from *subprocess* back to *nsIProcess* for starting/stopping adb. In further tests with the Simulator, @ochameau and I identified a serious regression with using *subprocess*: it doesn't always notice that adb has exited, probably because adb forks a server process that holds open the stdout/stderr file handles.

*nsIProcess* has its own problems, especially on Windows, where it opens a console window when you start it. But we're still better off using it until we can resolve that issue with *subprocess*. @ochameau is looking into it. In the meantime, I didn't remove the *subprocess* module from B2GRemote, as I assume we'll start using it again after we resolve the issue.