Transition towards passing through config to Systemd spawned services without providing dedicated config?

Learning more about systemd, I understand that we may want to expose a lot of configuration that could just go straight to how we configure the started systemd transient service. If its just passthrough configuration, should this project then provide a dedicated python traitlets based config option for it that we need to maintain? We do so for a few things now, but should we keep adding config to pass through systemd config?

Consider for example, in #125 we have a proposal to add `SystemdSpawner.cpu_weight` which maps directly to configuring `CPUWeight` with associated docs, and we provide similar docs as Systemd does.

In the jupyterhub distribution https://github.com/jupyterhub/zero-to-jupyterhub-k8s, we have had a similar situations that I found to be unsustainable. We provided the same config options for the Helm chart the project represents to configure the underlying GitLabOAuthenticator class for example. As soon as there was something new to configure, and a user wanted it, we had to expose it as a Helm chart config option. We decided that we simply shouldn't try to provide a 1:1 mapping of chart config, but instead provide a way to _passthrough config_, so that no matter what new functionality was introduced in some software dependency, it could be configured without the Helm chart knowing about it.

SystemdSpawner is in a similar situation I think, where Systemd has a lot of config options, and SystemdSpawner creates python based config to map to it.

I suggest we overview the existing config, and start ensuring users become confident on how to configure the spawned Systemd services with passthrough config directly, instead of relying on SystemdSpawner to be aware of all options provided by Systemd as it changes.