Introduce service wrapper permitting less stateful configuration

[charles-dyfis-net]

Config files for the previous wrapper could not be shared across machines, and could not be generated independent of or prior to creation of local system state, as they needed to be aware of filesystem UUIDs.

This wrapper permits more flexible configuration (including support for passing all parameters on the wrapper's command line, and not needing any on-disk files at all) while retaining support for the legacy configuration file format.

This attempts to address #80. The proposed wrapper is almost exactly identical to the one currently in use by NixOS (which is subject to some basic automated testing as part of that project).

_{This PR is admittedly written in a deeply opinionated style; arguments supporting that style are available via the freenode #bash IRC channel, and documentation (BashFAQ, BashGuide) maintained by members thereof, more specific references available on request.}

[kakra]

If it keeps backward compatibility, I like this. :-)

[charles-dyfis-net]

Theoretically it does, but it's only comprehensively tested on NixOS. I've done some smoketests with contrived examples of historical config files, but it'd be good to get feedback and review from someone with the real thing on hand.

[Zygo]

No objections at first glance. I'll have a deeper look later.

[kakra]

I'd vote for testing the backwards compatibility and if it works fine, start announcing deprecation of the old format during the next release cycle. We can then just drop support for the old format at some point (but still detect it and refuse to continue).

@Zygo I'll pick that into my integration branch and will work with it a while, we can then craft a PR from it.

[Freso]

Given that this PR is more than 6 years old now, does this need more than backwards compatibility testing? Or is that still the only thing blocking this?