add support for IP address family specifier for remote protocol

Add support for udp4/udp6/tcp4/tcp6 and the tcp*-client specifiers.

- refactor parsing of host:port:proto for --remote into a function
  nmovpn_remote_parse(). Also, search for the ':' delimiter from
  the right side. That way, one could use colons in the host, like
  using an IPv6 address "aa:bb::1::udp" (or just "aa:bb::1::").

- for IPv6 addresses (which also contain ':') we make a special exception:
  if we can parse part of the remote as valid IPv6 address
  (or as valid IPv6 address with square brackets), we don't split at the
  colon. For example, "dead:beef::1:1194" is taken as IPv6 address
  without port specifier. When the user wants the entre such an address,
  he can enter "[dead:beef::1]:1194".

- due to treating IPv6 addresses special, we cannot unambigiously import
  certain configurations. For example "remote a:" cannot be imported
  because both "a::" and "[a:]" would be wrong. That means, due to the
  special handling of IPv6 addresses, certain host names not be expressed.
  For example, during import we may import something different then was in the
  file. On the other hand, it only applies to configurations with hosts that
  have a colon, do not validate as an IPv6 address, but suddenly validate as IPv6
  address after appending ":" or ":PORT:". That is a known shortcoming, but
  shouldn't hurt because such DNS names seem very unlikely (they do have a dot,
  right?).

- during export, also consider '\t' as delimiter for mulitple
  remotes.

- during export, if port is unspecified but proto is given (a very
  unusual case), export port as "1194" instead of "443" for TCP. That
  is what server also does in case port is missing, and also is 1194
  the default port for OpenVPN.

https://bugzilla.gnome.org/show_bug.cgi?id=731620