Update libupnp to version 1.8.4.

For windows, the IPV6 preprocessor must be undefined. Or else
libupnp won't initialize. Added visual studio 2017 support
via one patch for windows that also combines previous windows
patches.

UPnPController: Class that the jami classes use to control the
opening and closing of ports. Every  service has it's own upnp
controller. The controller does it's actions by using the upnp
context class. Also refactored the functions used to add
mappings. Instead of using two different functions with
different types of parameters, we now use one function with
parameters that have default values. The logic stays the same
but the function call is more clear.

UPnPContext: Class that holds a (linked) list of discovered IGDs
and their corresponding protocols (which discovered them).
Whenever the controller wants to add or remove a mapping, the
context picks a valid IGD in it's list and uses the correct
protocol to complete the required action. This class also has
the ability to swap protocols for an IGD that was discovered
by more then one protocol.

UPnPProtocol: Virtual base class that defines the functions
needed by the context to use the corresponding protocol.

PUPnP: UPnPProtocol derived class that represents a upnp client
that uses the portable upnp library (libupnp). Every time the
client discovers a new IGD it uses a callback to add it to the
context's main IGD linked list. It also has an internal list of
IGDs that it discovered. Added features to this class include:
	- IGD event subscription.
	- Use UpnpInit2 function instead of deprecated UpnpInit
	  function. It's also supposed to support IPv6.

NatPmp: UPnPProtocol derived class that represents a upnp client
that uses the NAT-PMP library (libnatpmp). Unlike libupnp,
libnatpmp only supports discovering one IGD. Also uses callbacks
to add the IGD it finds to the context's main IGD class.

Also inclided debug warning prints whenever a controller opens
and closes the ports. That way we can keep track of whenever
the application opens and closes ports on the internet
gateway device.

Gitlab: #96

Change-Id: I199271edac2c6d93dc60c24e2e2aefe36de7950c

Change-Id: I30ca1d3cc90f1ed30beff1934e8eff66820e61ab

Change-Id: I02061e1319499e694817000e6184d1735c67261f

Change-Id: If991ec828c34a6b51c1aa12e0f316abf76a5c781

As contributed by Uwe Kleine-König <uwe@kleine-koenig.org>:
 - https://bugs.debian.org/884249

The compat code needs atleast upnp 1.6.25

Change-Id: Ia5e50dc362a64b4acd252dac5137e2aba4795064

After removing the boost dependency, the Ring UWP was unable to load
accounts with upnp enabled, as a deadlock would occur within the
threadpool initialization rountine of libupnp. I think the windows store
build of pthreads was preventing win32 thread management api symbols
from being defined. Something which loading boost must have been doing.

- Bumps pthreads-win32 from 2.9.1-release to 2.10.0-rc
- Builds a win32 static lib without windows store flags and uwp libs
- Modifies the libupnp and threadutils vs project patching

Change-Id: I3f43a066d86d284c614521fdb016810148590e70

- Changes fetch scripts urls to archived tarballs if possible to
  facilitate caching of the contrib source on the UWP Jenkins
  build machine.

Change-Id: I51eac783eea964bfe08727baf1ad7b9e08a5096d
Tuleap: #790

Change-Id: I0e4dd4e08d7aab7625e5728d833c0f8a556a175d
Tuleap: #790

- This patch allow us to build 64bits version of
the daemon (and thanks to that LRC and client too)
- We should essentially gain performance in CPU intensive task
like video processing

Depends on yaml-cpp bump that fix x64 mingw compilation

Change-Id: I32c7bafba0eddfa8a6779e1c13bde2ea56bf904b
Tuleap: #387

Refs #77776

Change-Id: Ifad20e9a9da301e11641f186f88f45e62940051d

Sourceforge is down.

Refs #77776

Change-Id: Ic9b77269d0780b5c2c30c72d3290a0e4626f3f22

Refs #71910

Change-Id: Iab724e6c9b9f6e412623a125a5bb076d3c78a57e

Avoid conflict with uuid

Refs #67175

Change-Id: I456da73cd33847603843d1b5bb9739c5ca1b5350

Refs #68986

Change-Id: Ia95b140e4f4d6625d1df12d52a40414482b2e773