Fix issue with unresolved external symbols for the gather and scatter classes by adding them to the MSVC 2010, 2012, 2013 and 2015 projects.

Solution: add make test to the cmake/ci_build.sh script

Solution: add macro in ZMQSourceRunChecks.cmake and optionally
include the TIPC sources if the support is available.
More importantly, only run the TIPC tests if the support is there.

Solution: check for availability in autoconf and cmake, and if not
available fall back to random file name rather than random directory.

A Visual Studio build from master (commit id: dac5b45d) using the v140_xp toolset yields a binary that is not XP compatible.

Two libraries contain exports that cannot be found:
 -  IPHLPAPI.DLL : if_nametoindex
 - KERNEL32.DLL : InitializeConditionVariable

The latter export is already dealt with in the file './src/condition_variable.hpp'; however this requires setting the _WIN32_WINNT pre-processor definition.
I am not experienced enough to figure a work around for the 'if_nametoindex' method, so I have created a new pre-processor definition 'ZMQ_HAVE_WINDOWS_TARGET_XP' and removed the calling of the function with the limitation that these builds cannot handle a IPv6 address with an adapter name.

To make it easier for people targeting XP with an MSVC build I have modified the MSBuild property file to add/modify the pre-processor definitions if they are building using a XP targeting tool set; such as v140_xp.

* Added a new .gitignore file for excluding Visual Studio build output any popular plug-in generated content. (This was copied from the GitHub project https://github.com/github/gitignore).
* Removed the basic ignore settings from the root folder in favour of more precision within the subfolder's .gitignore file
* Added the new VC compiler's experimental Intellisense database file

All the older (vs2010 -> vs2013) projects had copies of the Visual Studio 2015 MSBuild applied to them when running the 'configure.bat' batch file. Any modifications to a property sheet was not applied to the other Visual Studio versions' projects unless the batch file was re-executed.

* Modified the older projects to reference the Visual Studio 2015 property sheets so changes are immediately applied
* Removed the batch file copy steps (which left the repository very dirty after execution)

Solution: update them.

Solution: pass built-root when calling coveralls, to help it find the
right path to the source code.

Solution: update builds/valgrind/valgrind.supp to ignore glibc's
__libc_freeres calls. This code runs after the program exits, and
tries to de-allocate memory allocated internally by glibc, so it has
nothing to do with libzmq code. This suppression is added by default
in newer versions of Valgrind, not yet available on older
distributions.

Solution: run Valgrind only on the default Linux build to avoid
increasing the runtime.

Solution: remove temporarily until proper message limits have been
implemented, then a more granular test case can be added without
such high requirements which are problematic in embedded environment,
build systems, VMs and CI systems

Solution: add new coverage build, and upload results to coveralls.io

Solution: Modified projects to create PDB file for RELEASE targets
	- also spread precompiled settings to all DevStudio solution versions

This change affects Windows builds only

Solution: Enabled precompiled header settings in all targets
Before build time: ~6min 49 secs
Stop  Time: Fri 03/04/2016  8:29:50.13
Start Time: Fri 03/04/2016  8:23:00.28

After build time: ~4min 19 secs
Stop  Time: Fri 03/04/2016 12:12:10.24
Start Time: Fri 03/04/2016 12:07:51.78

Solution: Added ability to do equivalent of a "make clean" by executing:

O:\git\libzmq\builds\msvc\build>buildall.bat clean
Start Time: Fri 03/04/2016 14:33:56.50
Cleaning without libsodium
Cleaning ..\vs2013\libzmq.sln... ()
Platform=x86
Configuration=DynDebug
Configuration=DynRelease
Configuration=LtcgDebug
Configuration=LtcgRelease
Configuration=StaticDebug
Configuration=StaticRelease
Platform=x64
Configuration=DynDebug
Configuration=DynRelease
Configuration=LtcgDebug
Configuration=LtcgRelease
Configuration=StaticDebug
Configuration=StaticRelease
Cleaning complete: ..\vs2013\libzmq.sln

Stop  Time: Fri 03/04/2016 14:34:01.84
Start Time: Fri 03/04/2016 14:33:56.50

A clean takes ~5 secs to complete.

Solution: change builds/msvc/Makefile.am to reference vcxproj files
instead of props files.

Solution: change builds/Makefile.am to reference builds/android
instead of builds/qt-android.

Solution: remove references to builds/cmake/Makefile* since they no
longer exist.

Solution: The Coverity Static Code Analyzer was used on libzmq code and found
many issues with uninitialized member variables, some redefinition of variables
hidding previous instances of same variable name and a couple of functions
where return values were not checked, even though all other occurrences were
checked (e.g. init_size() return).

Solution: Corrected Toolset setting where needed and inprove compilation speed
by adding defintion of WIN32_LEAN_AND_MEAN prior to any Windows specific
include files, which skips non-essential definitions during compilation.

Solution: Corrected Toolset setting where needed and inprove compilation speed
by adding defintion of WIN32_LEAN_AND_MEAN prior to any Windows specific
include files, which skips non-essential definitions during compilation.

Solution: Phase II - made compile using precompiled header

Solution: in project.gyp, define _WINSOCK_DEPRECATED_NO_WARNINGS

Solution: Use CMD.EXE environment variable to extract DevStudio version
number and build using it. This even supports machines with multiple
DevStudio versions installed, as long as the build for each version is
done on a separate window with the correct environment.
If multiple version builds are desired from a single CMD.EXE, edit the
buildall.bat file to uncomment the build statements for each specific
version desired.

Solution: override in project.gyp, for Linux and OS/X.

Gyp needs its own platform.hpp; there is no way to delete this
file automatically.

Solution: copy gyp's platform.hpp into src, so that things build
properly no matter what the starting state. If you build with gyp
and then try to build using autotools' makefile, you'll get an
error from the platform.hpp.

Solution: add .gitignore in builds/gyp

Solution: raise to 16K

There were numerous small issues with test cases:

- some lacked the right source file header
- some were not portable at all
- some were using internal libzmq APIs (headers)

Solution: fixed and cleaned up.

Solution: offer a build.bat to help the user.

Solution: it's a lot of work to define the tests in project.gyp
so I did this using gsl to generate the JSON, from a small XML
list of the test cases.

To keep this, and the hundreds of .mk files, away from the root
directory, I've moved the gyp files into builds/gyp, where you
would run them.

It all seems to work now. Next up, OS/X and Windows :)

This is rather insane since the code knows well enough what systems
support if_nametoindex. I blame this on over-use of autotools early
in libzmq's days.

Anyhow, this breaks gyp builds on OS/X.

Solution: add ZMQ_HAVE_IFADDRS to build/gyp/platform.hpp for OS/X.

Solution: add necessary macros into builds/gyp/platform.hpp

Work for Linux now, other platforms to test.

Solution: establish a matrix of CI options. On one axis we have the
build system (autotools, cmake, android) and on the other axis we
have the encryption options (tweetnacl, libsodium or none).

Solution: use ZMQ_USE_TWEETNACL as a define as expected instead of
HAVE_TWEETNACL

I'm adding gyp support so that we can easily pull in libzmq
and other C/C++ projects into gyp packages, especially via
node-gyp.

Solution: add gyp definition

This works only for Windows, OS/X, and Linux. We set a single
macro in project.gyp according to the system, and the rest is
done in builds/gyp/platform.hpp. The values in that file are
not dynamic. Your mileage will vary.