Accessing a key in an array is not allowed when the array is not a variable but a value returned by a function.

This also required adding an additional argument to
SimpleSAML\Utils\Crypto::loadPrivateKey to ease in testing. Without
this additional argument, SimpleSAML_Configuration::getBaseDir eventually
gets called to determine the private key location.  This doesn't work
well with vfsstream. This argument shouldn't cause too much trouble, and
seems cohesive enough with the function's purpose.

Formatting, namespaces, phpdoc.

This enables too the implementation of additional contact attributes, as requested in #509 to support the SIRTFI framework.

This resolves #476.

It is possible that the current script ($_SERVER['SCRIPT_FILENAME']) is inside SimpleSAMLphp's 'www' directory. However, even if that's the case, we should not enforce our base URL (as set in the 'baseurlpath' configuration option) if the request URI ($_SERVER['REQUEST_URI']) does not contain the relative path to the script. This is the case of AuthMemCookie, for example, where accessing a random URL protected by Apache, leads to the execution of a SimpleSAMLphp script, where SimpleSAML\Utils\HTTP::getSelfURL() must not try to be smart when guessing the current URL.

Basically, phpdoc formatting and fixing some classes not using namespaces.

For some reason, these changes were not applied in the previous commit. Make sure we use the current interface of the SAML2 library instead of abusing the autoloader.

Reformat to comply with our coding guidelines. Migrate all the code to use the newest version of the SAML2 library, using namespaces. Fix some bugs. Move it where it belongs under modules/saml instead of modules/core.

Now we are finally using the 2.x branch of the SAML2 library, which was also migrated to use namespaces. Even though the library provides an autoloader that allows loading the classes with the old names using class aliasing, we need to do the migration in one commit (at least for most part of it). This is due to the way SimpleSAMLphp checks data types, using inheritance to check objects agains abstract or more general classes. Even though class aliasing works, there's no way to replicate those relationships, and type checks that use the old class names will fail because the aliases are virtually new classes that don't inherit from others.

PHP 5.3 and HHVM do not include the built-in server (or in the case of HHVM, not with the same syntax).

This test works as a demonstration on how to test our web interface endpoints.

With this script, which will be executed for every request performed to the built-in server, we can preload the configuration from a temporary file, making it possible to configure SimpleSAMLphp dynamically when testing.

With this class we can run PHP's built-in server specifying the document root (defaulting to the www directory) and a "router" file, which the server will execute for every request received. This is useful to allow testing of the web interfaces as part of our unit testing setup.

Recent fixes for URL guessing and building addressed bugs in the code that were preventing the 'baseurlpath' from being used properly. However, they introduced a new issue, as the code was assuming the current URL would always point to a SimpleSAMLphp script. This is not always true, of course, as any script can invoke our API and end up trying to get its own URL (for example, when calling requireAuth()).

In order to fix this, we monitor mismatches between SimpleSAMLphp's installation path and the absolute, real path to the current script. When there's a mismatch, it means we are running a third-party script outside SimpleSAMLphp, and therefore we should NOT enforce 'baseurlpath'. This introduces an additional issue, as applications behind a reverse proxy may cause trouble to guess the right URL (we will use the URL as seen by SimpleSAMLphp in the server, which is not necessarily the same as the user sees with a reverse proxy in between). For the moment, we'll leave the responsibility to sort that issue out to implementors. It might be a good idea to add a page to the wiki explaining how to do this.

This resolves #418.