UPnP cleanup and fixes for #432

Code to fix the issues outlined in #432. The surgery was fairly invasive: I thought it best to leave the commits un-squashed so as to leave the transformations of the code as granular and obvious as possible. I'm happy to squash away if that's desired.

Notes:

* The generalization from 1 thing to n things made returning an error awkward. For example, if discovery fails on one device, that shouldn't affect the discovery of any other device. Mapping errors back to devices is awkward, requiring either parallel arrays or an additional field in the IGD struct, and much more complicated error-handling logic in the consumer. Since no error-handling logic beyond writing to log files was done by the upstream consumers, I elected to simply log errors to the debug log facilities instead of returning them to the consumer.
* I tested the changes with one of my local routers, Wireshark, and a miniupnpd instance in a VM. I didn't see a good way to automate testing of the discovery or port mapping mechanisms; the only readily testable portion of the API seems to be the search and port mapping request strings. These operations seem don't seem susceptible to regressions, but I can write tests if desired.
* Searching for multiple devices requires a bit of concurrency, which is frequently difficult to grok. I attempted to write the cleanest code possible and documented as well as I could, but I'd be particularly interested in feedback about how penetrable the solution is.
The `WANIPConnection` and `WANPPPConnection` services have an `ExternalIPAddress` state variable and an associated `GetExternalIPAddress` action. This information could be queried as part of the discovery process.

I wasn't clear about my meaning with the second option: the second option would definitely be a hack/work-around that would assume a single IGD on the network. It would most definitely be brittle and likely break in an environment with multiple IGDs.  Since the code for discovering multiple devices has already been written and seems to be working well, I don't think it would make sense to remove the multi-device discovery code, but it may not be worth increasing code complexity--which would increase the potential maintenance overhead--and delaying the 1.0 release of syncthing to accommodate multiple IGDs outside of the UPnP discovery process (e.g. in `main.go`). I'm personally eager to provide a complete solution, but maintenance overhead is a thing Jakob specifically mentions in the Contribution Guidelines, so I thought it'd be best to make sure the more extensive changes required to support multiple IGDs didn't fall into the "too maintenance-intensive" category.