unix-adapter: Link statically with cyggcc_s-1.dll and cygstdc++-6.dll.

 * At least for now, I'm shipping Cygwin/MSYS binaries.  On Cygwin (but
   not MSYS), the console.exe executable previously linked dynamically
   to cyggcc_s-1.dll and cygstdc++-6.dll.

   Linking dynamically with cygstdc++-6.dll seems risky for a binary
   not distributed by Cygwin, because G++'s Windows ABI is unstable, at
   least as of G++ 4.7, which turned on the __thiscall calling
   convention.  If a binary I ship ever comes into contact with a
   4.7-versioned cygstdc++-6.dll, then my binary will (very likely)
   segfault.

   So far, I've only observed this ABI incompatibility with MinGW,
   where a sufficiently upgraded MinGW configuration comes with a
   libstdc++-6.dll that is completely incompatible with every previous
   libstdc++-6.dll, so that every program built against the older
   libstdc++-6.dll segfaults immediately.  For now, Cygwin seems stuck
   at G++ 4.5, and my impression (possibly incorrect), is that G++'s
   Windows ABI was stable prior to 4.7.  I think G++'s Linux ABI is
   stable.  Presumably Cygwin will eventually update its compiler,
   though, so it makes sense to fix the problem early.

   I believe I originally chose to dynamically link the libraries
   because it was the default behavior, and I was afraid that a
   non-default option would break something.  It turns out that
   linking statically with cygstdc++-6 *does* break something -- it
   causes linker errors if the code uses std::cerr.  The workaround
   is not to use std::cerr.  This is not a problem for the
   unix-adapter, which already has to put up with MSYS' gimpy G++ 3.4
   compiler.
MSVC compatibility: Deal with snprintf and vsnprintf.

 * When building with MSVC, there is no snprintf function, but there are
   _snprintf, vsnprintf, and _vsnprintf functions (as well as many
   variations on these).  The MSVC _snprintf is not the same as C99's
   snprintf, and in particular, it does not guarantee that the buffer is
   NUL-terminated, whereas C99 does guarantee this.  I want the C99
   behavior, so add a c99_[v]snprintf functions in shared/c99_snprintf.h
   that provide C99 behavior.

 * Details:
   http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010
MSVC compatibility: Remove the {Agent,WinPty}DebugClient.cc hack.

 * With this hack, it's impossible to add all the .cc files to an MSVC
   project, because MSVC understandably thinks that
   agent/AgentDebugClient.cc and shared/DebugClient.cc are two separate
   C++ translation units.  I could rename DebugClient.cc, but it's better
   to just fix the problem with the Makefile.
Add a gyp project that can build winpty-agent and libwinpty.dll with MSVC.

Peter Rekdal submitted the original version of this file.  I made some
minor changes.

Update the .gitignore file to ignore files generated by building winpty
with MSVC.
In winpty-agent, print an error message if the arguments are invalid.

 * Some users might think they could run winpty-agent.exe.

 * Right now, when I run winpty-agent.exe from a cmd.exe command prompt
   window, it looks like winpty-agent.exe is segfaulting.  It *ought* to
   print an assertion failed dialog box.
Remove CRLF line endings from README.rst.

 * None of the other text files in the repository have CRLF line endings.
Remove unnecessary header files
Improve error message
Allow thirdparty to host datapipe themself. Also replace winpty_close() with winpty_exit() since closing the control pipe will cause child process to exit.
Resolve merge conflicts