Propagate cancellation tokens through the installer engine and the Config app

[johnsimons]

Retires the cancellation analyzer debt blocks in ServiceControlInstaller.Engine,
ServiceControl.Management.PowerShell and ServiceControl.Config.Tests, and
narrows the ServiceControl.Config block to the one boundary that cannot
carry a token. Phase 7 of the propagation work.

The engine change is what forces these projects to move together.
AbstractCommandChecks' eight abstract members take tokens, the prompt
callback becomes Func<PathInfo, CancellationToken, Task> throughout
PathsValidator, the installable bases and the unattended installers, and
ValidateNewInstance loses params so the token can be last. PowerShell's
PowerShellCommandChecks and the three New-*Instance cmdlets follow, along
with the Config app's ScmuCommandChecks, InstallerModule and add
attachments.

Two token drops are fixed in the Config app's Caliburn layer. RxScreen
received a CancellationToken in ActivateAsync and DeactivateAsync and
discarded it instead of passing it to OnInitialize, OnActivate and
OnDeactivate; RxConductorBase did the same in ActivateItemAsync and
DeactivateItemAsync. Both now forward it, so screen activation is
cancellable.

Command bodies reached through ReactiveCommand.CreateFromTask now take a
required token, which binds its Func<CancellationToken, Task> overload
and gives them a real one. Config's own Command.Create path bottoms out
in System.Windows.Input.ICommand.Execute, which returns void and has no
token to offer, so those command types keep a file-scoped block that says
so, and their call sites pass CancellationToken.None explicitly.

Caliburn's IClose.TryCloseAsync and IEventAggregator declare no token and
cannot be changed, so those are inline pragmas rather than fixes.