Revoke any cached authorizations before trying to change password mode.  This makes sure that we authenticate the user again even if we just did so (for UX consistency).

Note that this is kind of an involved change:

- I took out the trySetSecurity call which doesn't make sense anymore if we don't allow cached authorization.

- I changed the policykit agent to register as a session-wide agent (not just for the system-settings process).  This is because polkitd does not yet allow you to revoke cached authorizations for processes.  Registering and revoking as a session-wide agent should be fine.

- I also had to use the call to revoke all authorizations.  There is a more targeted call, to only remove one authorization, by ID.  But polkitd didn't let me find the authorization ID when I queried for it.  So...  I figured just revoking all of them was fine.  We are changing the password after all.  Either the user changes it and it makes sense to revoke all auths from the old password or the user fails to change it and it makes sense to revoke all auths as a security measure (some non-owner is holding the phone).  Between the problems revoking-by-process and revoking-by-ID, I get the sense that the revokation API isn't often used.

- Adding more calls to the policykit agent made it more noticeable that we were using a blocking call to wait for the agent to finish.  That's bad UX.  So I changed system-settings to call QCoreApplication::processEvents every now and then while waiting.

- Now that Qt was processing events while waiting, I had introduced a new problem: the user can interact with the main page (even pressing the "back" button) while the dialog is waiting -- you can see this by going to landscape mode).  So I made sure that the page and back button are disabled while the dialog is up.  (And to get access to the back button, I had to bump the Ubuntu.Components API version to 1.1 to get the 'head' property on a Page.) Fixes: #1371655
Approved by: Ken VanDine, PS Jenkins bot