This lets us give better feedback to the user about what's
currently happening.

Resolves #1

We need to be sure that some checks are performed in ProcessRequest() and not
call RunWpkgQuery() directly. It feels like encapsulating a private
RunWpkgQuery() inside a CommandHandler class which exposes a public
ProcessRequest() is the right way of doing this... but the requirement to have
shared state between the WpkgInstaller class and that hypothetical class means
that's going to get ugly too. Thus, even though reflectively checking our
caller feels pretty ugly, I'm going with it as the lesser of two evils.

This is a holdover from when the UI was designed around clicking
menu options in the tray icon context menu. That's now all moved
to buttons in the status window.

Having the localised pattern of a particular command thread be of the form
* Go to busy
* do stuff
* Go to idle
seems more logical and reliable than scattering state changes between
different function calls!

This will make it easier to call methods on statusWindow from
arbitrary points in the code.

Resolves #2
Reverts 51fc544d

Close() destroys the object, after which we can't reopen it.

Now that we run wpkg commnds in a thread, we need to add a delegate to e.g.
report on the result of running a query command only once the thread in
which the query command is running has finished.

In order to properly support the possibility of multiple clients,
we need ProcessRequest() to return asynchronously.

I have been continuing to conflate 'the current state of the service'
vs. 'the result of the last command the service ran'. The latter may
still be useful to report back to the clients, but the manner I've
used this in so far has been more in line with the former. So let's
consistently Make It So.

Redo notifier menu items: they now show relevant dialogs, with buttons to perform query/sync actions