* Migrate assertions to Webmozart

Broken during refactoring in 6607b7fb

Non-file-upload crashed on Symfony request building.
File upload crashed because of not using the actual path.

* Added Kernel class to handle request

* Kernel handle request

Kernel is loaded in SimpleSAML\Module class
Removed Router and ControllerResolver classes

* Added route command (squash)

* Use symfony application and cache

* Updated to today's standards

* Fix for Symfony4 & Catch environment from ENV variable

* Standardize location of routes/services files

* Trying to make slashes work properly in all situations

* Convert XML to YML

* Fix some template-names and endpoints

* Rename Controller-classes

* Update dependencies

* Fix routing files

* TooManyArguments

* Fix TypeCoercion

* PSR-12

* Fix rebase mistake

* Rebase lock-file

* Fix Psalm

* Add strict_types declaration

Co-authored-by: Sergio Gómez <decano@gmail.com>

* Raise minimum PHP version to 7.0

* Remove tests pre-PHP 7.2

* Upgrade dev dependencies

* Ignore tests for deprecated class

* Add typehints; not touching public API

* Remove none-array replacements-param; old behaviour from pre-1.4 release

* Psalm fixes

* Add upgrade notes

* PSR-12

Closes #1227

PSR-12 compliancy

* Ensure getConfig* functions can only return Configuration

* Cleanup after #1189

* Deprecate Configuration::getConfigList

This resolves #1023, resolves #1093 and closes #1095.

Fixes for the remainder of lib/SimpleSAML

This introduces the following:

- The use of Request objects to handle request data to controllers.
- The use of Response objects to model responses that should be sent to the browser.
- The use of "controllers" that are responsible for translating a request into a response.
- The possibility to define your own URLs on each module by specifying them, together with their controllers, in a "routes.yaml" file in the root of a module.
- The new UI is completely separated from the old, so "usenewui" must be set to "true" in the configuration.
- Twigified templates are not used unless we're using the new UI, or the twig template is part of a theme.

Doing so allows us to mock the class. Otherwise, the _autoload_module.php is always called first, and when it tries to register the functions from that class, it automatically autoloads it, making it impossible to mock it afterwards.

Instead of one cache, we need to use two: one for the list of modules available, and the other for the details for them. Those caches should be filled independently, so that someone calling getModules() does not trigger the code checking of the modules are enabled or finding their hooks.

The issue here is that every time we need to list the modules or check if they are enabled, we just iterate over the modules directory and subdirectories, which is terribly expensive. Instead of doing so, we build a cache of modules specifying if they are enabled or not. In the end, this is also fixing another issue, given that enabling/disabling a module in the middle of a request being processed could lead to inconsistencies and unexpected behaviour (likely exceptions and horrible crashes). Modules should be checked in the beginning of a request and their state (enabled/disabled) frozen until the request is processed to avoid that, and this is the way to achieve so.

Additionally, we take the chance to check if modules are enabled when we search for them. This reduces the processing time to around a third of the original without this fix.