feat: Switch to WireGuard and add systemd integrations

[tprasadtp]

🎉 New client written from scratch. Please try rc/beta tags and report bugs if any.
To see docs for OpenVPN based container after the PR is merged, see https://github.com/tprasadtp/protonvpn-docker/tree/release/v5.

To try the docker image use ghcr.io/tprasadtp/protonwire:unstable

🎉 New Features 🎉

• Drops OpenVPN support and uses WireGuard 🎉 (Closes [BUG] - support for Wireguard #72)
• Ability to provide private key via podman secrets, systemd credentials and env variable.
  This should (also close Clarify settings, specially user/pass #182).
• Adds support for systemd-resolved integration.
• Adds systemd status, watchdog and notify support. (Closes [BUG] - Unable to get other containers to use protonvpn using Podman #111)
• New option to disable healthchecks via cli flag and environment variable.

🔥 New Experimental Features 🔥

Warning

Experimental features are not covered by semver compatibility guarantees.

• Add kill-switch support via ip routing rules. This does not make use
  of ufw/iptable/nftables. This uses ip rules to create a sinkhole routing table which blocks all
  internet bound outgoing connections. More specifically, this blocks all subnets specified via
  PROTONVPN_ALLOWED_SUBNETS_IPV4 and PROTONVPN_ALLOWED_SUBNETS_IPV6 You don't need to tweak these two
  env variables unless required, sane defaults are used if not specified. (Closes [BUG] - Network traffic leaks during reconnections #122)
• For IPv6 only networks and networks with custom routing requirements, where default excluded routes
  are not suffiecient, one can overrride PROTONVPN_ALLOWED_SUBNETS_IPV4 and PROTONVPN_ALLOWED_SUBNETS_IPV6.
  Both use use comma separated list of CIDRS.

⚠️ Breaking Changes ⚠️

• Removes support for PROTONVPN_EXCLUDE_CIDRS as protonwire will exclude IPV4 addresses from Special-Purpose Address Registry and non-routable IPv6 addresses from being routed over VPN by default. (Closes [BUG] - Webinterfaces not available when connection container through ProtonVPN #146, [BUG] - Cannot connect to port in another network #141, Question:  #176)
• Drops upstream protonvpn cli from docker images. This is not covered by semver
• Due to changes introduced by ProtonVPN API automatic server selection
  is no longer supported. You can add --p2p, --streaming, --tor
--country flag to enable client side validation of server features, but
  client can no longer select the "best" server as its variable and non-deterministic, depending on
  like server load, client IP and client latency and this cannot be supported.
  This closes Question #174, and also Adding options for SECURE_CORE and TOR Connections, modified healthch… #161 as partially resolved.
• Uses smaller alpine base image. (This also Closes fix: Install iputils-ping #109 as ping is now included via busybox)

🐛 Bug Fixes 🐛

• Document ability to disable healthchecks. (Closes [BUG] - public IP not matching proton server IPs #104)
• Document healthcheck command (Closes How to check if vpn is running? #152).
• Add ping command to docker images. This is more of a side effect due to busybox
  bundling ping command, nevertheless closes fix: Install iputils-ping #109.
• Document usage with podman. (Closes [BUG] - Unable to get other containers to use protonvpn using Podman #111)
• Use custom API for fetching server metadata. (Closes [BUG] - Community client no longer works with most servers #126, [BUG] - public IP not matching proton server IPs #104)
• Change docs to use port instead of expose. expose was used as port
  publishes the port and can potentially bypass firewall rules. (Closes [BUG] - Webinterfaces not available when connection container through ProtonVPN #146, [HELP] How does this exactly work? How can I access services behind VPN?  #105).

🚧 Known Issues 🚧

• Port forwarding is unsupported.
  Reverts Added natpmpc #179, as static port forwarding is not supported by ProtonVPN (for now) and alpine
  repositories do not contain natpmpc. Thus, [RFE] - Port Forwarding #125 (and its duplicate [RFE] - Port Forwarding #142), is still unresolved.
• If you assinged routes manually via ip route, those routes may bypass killswitch!