Fix #994204 (restarting of services marked --no-stop-on-upgrade)

There are two bugs addressed in this request; mostly it undoes the original fix for #989155, and then fixes that in such a way that #994204 does not occur.

The original issue (#989155) dealt with moving a package from the new default restart behaviour (--restart-after-upgrade, indicating services should be restarted in a single step after file unpacking) to the older restart behaviour (--no-restart-after-upgrade, indicating services should be stopped prior to unpacking, then started again at the end of installation. The crux of this issue is, with the --no-restart-after-upgrade option, two versions of the package are involved in stopping and restarting the service. Specifically, the prerm script of the old version of the package stops services, then the postinst script of the new version of the package starts services.

The original fix for this issue (in commit 6067bc2f and 5b27a541), handled this by leaving the stop behaviour in prerm and modifying the start behaviour in postinst to always restart (with the unfortunate consequence found in #994204).

I think it may be preferable to instead move the stop behaviour to the preinst script of the new version of the package so that both stop and start behaviours are encapsulated in a single version of the package (and hence can be freely moved between). This also means that postinst script's prior behaviour can be restored.

To that end, this MR first reverts the two commits associated with #989155, then adds a third commit that adds a preinst script for dh_installinit and dh_installsystemd (and tidies up a little of the substitution handling in the former). The test suite still passes for me, and in a few test packages I've attempted building with the patched version I think the restart behaviour is now fixed in the various scenarios outlined above (--no-stop-on-upgrade for #994204, and moving --restart-after-upgrade to --no-restart-after-upgrade for #989155).

However, my Perl skills are extremely rusty, and this is not an area I'm overly familiar with, so any additional scrutiny is very welcome!