Specify Buster-based securedrop-workstation template as new default

[eloquence]

Part of #306, dependent on #344 and the final task of the Buster migration: Once all dependencies are met, we can declare the Buster-based template to be the new default, after which a make all run should provision a SecureDrop Workstation in which all VMs are fully based on Debian Buster.

[emkll]

For in-place updates, there are two approaches we can consider. There's added complexity compared to #329 , because the templates are cloned from a base template. We can either

1. Create a whole new set of templates when changing distributions (e.g. sd-svs-buster-template), and then perform the swap and remove the old templates at the end of the run as part of the cleanup task. In this case, it appears that we cannot rename the templates, template names are read-only when using qubes-prefs (It can only be done by the UI)
2. At the start of the run, if the template is debian-9 based, swap it with a known exiting template (e.g. securedrop-workstation-buster), delete the existing (debian-9) template, and then continue with the install, creating all buster-based templates with a naming scheme consistent with the current approach (sd-svs-template).

Option 1:
(+)Name for templates changes
(-) Name for templates is distibution specific
(-) Larger diff overall, requires replacing names for all the templates

Option 2:
(+) smaller diff
(-) requires more careful logic for conditional execution of old template cleanup (perhaps using tags)

I have tested both options and believe they are both feasible. I would be inclined to go with option 1 since option 2 requires a fair amount of conditional logic, thus more error-prone and harder to maintain.

[redshiftzero]

agreed on 1, a more straightforward implementation even if the diff is larger is wise. I don't see any issue with having the template names distribution specific (indeed, it might even be advantageous so admins/devs can easily see at a glance in the name which distro they're on)

[emkll]

An additional challenge with the in-place upgrade, that was also present in #329: When changing a template for a given VM, this VM cannot be powered on. This means that we would need to either:
a) automatically shut down VMs which templates need updating (and interrupt a user's
b) have the update user-intiated