The SAML2int spec suggests that IdPs should advertise two name
identifier formats, and SAML itself supports this. It seems that
SimpleSAMLphp does too, when handling metadata in XML (it is implemented
as an array). However the internal metadata format uses getString,
limiting us to only a single NameIDFormat. So far as I can tell, all
that's needed to fix this is to change the metadata parser to use
getArrayizeString to accept either a string or an array, and to cast
that as a string when necessary.
This may solve issue simplesamlphp/simplesamlphp#91

Add initial support for SAML Subject Id Attributes

The OASIS spec [SAML V2.0 Subject Identifier Attributes Profile](https://wiki.oasis-open.org/security/SAMLSubjectIDAttr) defines two new standard attributes intending to replace use of persistent NameIDs and the eduPersonTargetedID and eduPersonUniqueId SAML attributes. The updated Kantara [SAML V2.0 Interoperability Deployment Profile](https://kantarainitiative.github.io/SAMLprofiles/saml2int.html) will also standardize on these new attributes (cf. SDP-SP15 ibid.).

This commit adds the two new attributes:

* to the URN attribute maps
* to attribute definitions and translations of the locale system
* to the smartattributes:SmartID auth proc filter (after any other SAML attributes, but before the non-SAML ones).

Support for saml2int SDP-SP16 (attribute requirements signalling via Entity Attributes) is not included here.

Upgrade gettext to latest version

Make sure that session is closed and only then update cookie params

Add missing catalan language

Update config.php
Update header.php

Make authfacebook compatible with new facebook response query params

Do not include query parameters when constructing redirect uri for use with
the `access_token` endpoint.

Background:
Depending on your Facebook app configuration Facebook may return additional query
parameters after a a user authorizes an app. The module was incorrectly adding
these extra params to its redirect uri and generating a redirect uri that is
not in the app's whitelist.

People might just copy-paste it, while there's usually no reason
to enable this by default for new installations; specially not as
a QucikStart.

Otherwise new installs that do not have this extension get a "white
page" with an exception in the logs, because the check happens before
the page reports on the required modules. This will no doubt lead to
many support questions on the mailing list.

I had to rename the class because 'static' is a protected keyword, but forgot to rename the file