This uses the jupnp stack to discover and map ports.
It does not use jupnp's built-in PortMappingListener due to
shortcomings:

1. We need to determine which address to request mappings to dynamically
   instead of specifying the address to map in advance
   since we can only know which address is appropriate after we
   determine which interface has an IGD on.
   We instead use the address that the IGD was discovered from.
   This may not be the most preferred address to use, but it does
   guarantee that it works with routers that reject requests to map ports
   to addresses that the request didn't come from.
2. We need some additional callbacks to be able to wait for some device
   to be discovered and some port to be mapped in order to present
   appropriate error messages.
3. My router doesn't support InternetGatewayDevice:1,
   only InternetGatewayDevice:2, so I needed to add additional checks.
   This is fine because PortMappingAdd is supported on both.

The jupnp data model isn't ideal, since it broadcasts from every IPv4
address and some routers (i.e. mine) will respond to discovery
broadcasts from every address it has, including a few IPv6 ones,
and it assumes that if it gets a response from a different address
then the UPnP device has changed address and so is a new device,
triggering device removed and new device callbacks,
which we have to request a new port mapping for because we can't tell if
it's a new device or not.

As a result, port mapping involves a number of port mapping requests
equal to the number of non-loopback IPv4 addresses you have
multiplied by the number of addresses the IGD responds from.