Add modes to the wireguard backend to use a single tunnel for both address families

[sjoerdsimons]

Description

Allow users to configure a wireguard backend mode which determines how
the tunnel(s) are setup. The current method (a tunnel per address
family) is kept as a "seperate" mode on top of that three modes are
added that use a single wireguard tunnel overe which traffic for both
network families travels. Specifically the following new modes are
added all using a single tunnel:

* ipv4: Use the remote nodes ipv4 address as wireguard pper
* ipv6: Use the remote nodes ipv6 address as wireguard pper
* auto: automatically determine which remote node address (v4 or v6) to
  use. (default)

The main benefit of these new modes is that all combinations of nodes
only need to have a single viable network path between them to setup the
full mesh. For example if in a dual-stack setup (some) nodes have no viable
ipv4 path the mesh can simply run over ipv6. This also simplifies
firewalling as it only requires a single port to be open. And finally it
avoids having odd issues where node pods can connect over one address family
but not the other due to only one tunnel having connectivity.

Release Note

The wireguard backend now supports a mode parameter to determine how the wireguard tunnel(s) are setup:
    * auto - Single wireguard tunnel for both address families; autodetermine the preferred peer address (default)
    * ipv4 - Single wireguard tunnel for both address families; use ipv4 for the peer addresses
    * ipv6 - Single wireguard tunnel for both address families; use ipv6 for the peer addresses
    * seperate - Use seperate wireguard tunnels for ipv4 and ipv6

[sjoerdsimons]

fwiw the first commit (private ip helper) is from #1513 which i had to close as the source branch name confuses the flannel testsuite... Not sure if it's worth re-opening by itself; the outstanding question afaict there was from @luthermonson whether we can get rid of that code if flannel bumps its golang version (which iirc is the case, but bumping golang versions is not my choice to make :p)

[luthermonson]

@manuelbuil going to need you to look at this one... it's probably up your alley