Provide a way to update existing accounts' authentication parameters

[Alberto Mardegan]

Sometimes it happens that the authentication parameters change. Some of the possible reasons are:

a) the provider itself changes the authentication method on the server side
b) we want to change some authentication parameters in order to improve the user experience (for example, request the mobile version of the website, or do some tricks to get a longer-lived access token)
c) we need to request additional permissions for some new application
d) new application key

With the possible exception of the last point, in all the other cases we definitely want to update the parameters on the user's existing accounts (upgrading the application keys might not be desirable, if the existing ones work and there is some user quota restriction on all the application keys emitted for this provider).
At the moment, this does not happen: if the authentication parameters stored inside the account are no longer working, currently the user needs to delete the account and recreate it.

To solve this problem, we need to find a way to update the existing accounts' authentication settings -- and figure out when this is actually needed.

PROPOSED SOLUTION
=================

The updating logic should belong to the account plugin; the main question is how and when to trigger the update.
When invoked by the GNOME control center applet, the account plugin could check the settings on the account and update them as needed.
  Pros:
  - the account plugin could do this before starting the reauthentication, when accounts need to be re-authenticated.
  Cons:
  - would not automatically cover case (c): the new applications get a valid access token anyway, but it has insufficient grants. So, the account is not set to need-attention state, and the user might not visit the control center.

Case (c) could probably be handled by the application itself: it could explicitly specify the OAuth scopes it needs before starting the authentication, if they are a superset of those requested by the account (this can be done, for instance, by writing the scopes into the libaccounts's .service file).