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.

Running `make cross` now produces 386/amd64 versions of `docker.exe`!

### 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>
It's really sixes, IMO.  At this point the list of platforms we build for that _don't_ support this particular call is shorter than the list that do, so this makes sense to me, but I don't think one is really much better than the other.

One benefit for this way is that when someone goes to port a new platform, they automatically try compiling this file, which will either just work, or will fail and give them an obvious indication that they need to adjust the build tag here (where the opposite build tag would just succeed and then fail at runtime with a "not implemented" error).  I'm all for build-time failures. :+1: