Windows port of Docker Client

### Introduction

This pull request contains the set of changes to compile and get the Docker
client working on Microsoft Windows.

Changes were mostly around `pkg/term` to get the `docker attach` and other
TTY-involving parts working on Windows terminals, `pkg/archive` and `utils`
which rely on Unix-specfic calls or structures like stat and other things
like home directory or path separators.

We haven't gotten the CLI integration tests running on Windows, yet,
therefore functionality is mostly verified manually (more about this below).
There are known bugs, which we are looking forward to fix very soon.

Since some of the client code uses packages which contains daemon code (and
therefore closely coupled to Linux), we had to provide alternative implementations
to those using Go build tags. Those functions mostly return errors
when they are called because they shouldn't be called on client code paths.

### Known issues 

* **Integration-CLI tests not executed:** Most of this test suite assumes
  the daemon is running on the same machine as the client (not possible on Windows, yet)
  and uses Unix sockets to verify the results. These need to be skipped, where
  applicable, or these tests should be converted to use the Remote API over HTTP
  instead of using Unix sockets.
* **Path issues:** Due to the difference between Unix and Windows path separators,
  functionality involving Dockerfile and .dockerignore (e.g. `docker build`) are not
  yet working properly.
* **ANSI.SYS dependency for TTY:** ANSI escape sequences used by TTY terminal code
  (e.g. `docker attach`) are not natively working in the Windows Command Line (cmd.exe)
  or PowerShell. The reason is, ANSI.SYS has not been shipping since Windows 7.
  However, other terminal emulators like [ConEmu](https://code.google.com/p/conemu-maximus5/)
  or ANSI.SYS alternatives like [ansicon](https://github.com/adoxa/ansicon)
  solve this problem. We will be searching for solutions that work out-of-the box.

![](http://cl.ly/image/3g0V3w352Y1D/Capture.PNG)

Signed-off-by: Ahmet Alp Balkan <ahmetb@microsoft.com> 
Signed-off-by: John Gossman <johngos@microsoft.com>
@tiborvass pkg/signal is used mostly for looking up signals by name and forwarding signals. In api/client case (monitorTtySize & exclusion of SIGCHLD in forwardAllSignals), we just need those specific signals. And in Windows case, these two are not available on Windows, therefore we provide invalid signals on _windows implementation. Should it still go there?