None of the branded providers (eg., Google, Facebook and Windows Live)
should ever have an invalid certificate; and in this version of GOA,
that's all we have. So set "ssl-strict" on the SoupSession object
being used by GoaWebView.

Reviewed-by: Debarshi Ray <debarshir@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=693214

This reverts commit a4653300.

That commit was for master, not gnome-3-4 branch.

This is useful because Facebook sends the OAuth2 log in page in the
wrong language unless the Accept-Language header is set.

Fixes: https://bugzilla.gnome.org/675930

We don't want to break string freeze for error messages unlikely to be
ever displayed to user.

A new convenience method goa_provider_delete_credentials_sync has been
added.

Fixes: https://bugzilla.gnome.org/654168

To fix a broken 3.3.92 tarball.

See:
http://developers.facebook.com/roadmap/offline-access-removal/

The client secret is now obsoleted by the client-side auth flow use.
Hardcode an already existing "GNOME" Facebook app id.

Fixes: https://bugzilla.gnome.org/672060

See:
https://developers.facebook.com/docs/authentication/#client-side-flow

Fixes: https://bugzilla.gnome.org/672060

Backport: Changed translated error message to not break string freeze.

When a client side auth flow is performed, there's no need for the
client to pass the authorization code to the remote application in
order to allow her to be authorized by the provider.

Under this flow the user requests directly for the token (using
request_type=token query, which should be set in the authorization uri
builder), which allows the provider to give the application/client
directly the access token,skipping a step in the
authentication/authorization flow.

This means that under a client side auth flow no authorization code is
ever present.

Fixes: https://bugzilla.gnome.org/672060

You usually have a border on any text or web widget.

Fixes: https://bugzilla.gnome.org/660514