Split netplan-generator into separate package to make the Python dependency optional

Netplan consists of multiple components, some of which are optional:

• libnetplan: A C library all of Netplan's core logic (YAML parsing, data validation & generation of systemd-networkd/NetworkManager configuration)
• netplan-generator: A systemd-generator that runs at system boot time to generate sd-networkd/NM configuration from Netplan's YAML configuration in /etc/netplan/ (Written in C and linked against libnetplan.so)
• (optional) netplan-cli: Some CLI tools to interact with Netplan at runtime (netplan get/set/try/apply/status/...), those are written in Python.
• (optional) netplan-dbus: A daemon providing certain D-Bus methods on the io.netplan.Netplan interface. For historical reasons, this daemon is shelling out into Netplan's CLI tools for some operations (libnetplan wasn't a thing back then). It should eventually be ported to libnetplan.
• (optional) netplan.io: Top-level package, pulling in all of Netplan's components. Contains the Netplan (Python) CLI and a daemon providing Netplan's D-Bus interface.

All of those components (except libnetplan) have historically been part of a single netplan.io package (also called nplan in the past, due to a namespace conflict with the unrelated netplan package from old-old-old-stable times).

We want to keep the netplan.io package (for now) to provide a clean upgrade path for users, that's pulling in all of Netplan's components. Eventually, we want to make that package transitional in favor of a netplan package, taking over the name of that old unrelated software (which isn't a thing anymore nowadays). But that's for another time.

We want to split out the netplan-cli parts, which is the only component depending on Python and not necessarily needed to use Netplan (e.g. in cloud images we don't need Netplan's interactive configuration tools). This will reduce Netplan's base footprint by a lot, as discussed on debian-devel. This package needs to depend on netplan-generator as that's the component it's controlling.

While on it, we split the netplan-generator into its own package (just depending on libnetplan), to prepare for the eventual netplan.io -> netplan top-level package rename. Installing netplan-generator (+ the library) will be the minimal Netplan configuration.

The netplan-dbus component needs to move into its own package, as it has a dependency on netplan-cli and is not necessarily needed to use Netplan. The CLI/Python dependency should eventually go away, at which point we can change this package's dependencies to just libnetplan.

Future work:

• Split out netplan-cli and netplan-dbus (from netplan.io) as described above.
• Transition from the netplan.io to a netplan package name for the top-level package, to avoid user confusion.
• Once upstream declares a 1.0 release & stable API+ABI (probably in 2024), we will bump the soversion and rename libnetplan0 to libnetplan1
• Once upstream publishes higher level Python bindings for libnetplan, those will be added as a python3-netplan package.