This section is now unused as the security configuration has to happen on the webserver layer since https://github.com/owncloud/core/pull/14651

Replaces the OC_Mail and phpmailer with SwiftMail allowing us to mock it properly.

Fixes the unit test execution on master on local machines and https://github.com/owncloud/core/issues/12014

Conflicts:
	3rdparty
	lib/private/server.php
	lib/public/iservercontainer.php
	tests/lib/mail.php
	tests/settings/controller/mailsettingscontrollertest.php

Conflicts:
	3rdparty
	lib/private/mail.php
	lib/private/server.php
	lib/public/iservercontainer.php
	settings/ajax/lostpassword.php
	settings/application.php

* Original avatarcontroller migrated to the appframework
* Added DataDisplayResponse that show data inline in the browser (used
  to retrun the image)
* Removed some unneeded code
* Added unit tests for the avatarcontroller

Doing this in the PHP code is not the right approach for multiple reasons:

1. A bug in the PHP code prevents them from being added to the response.
2. They are only added when something is served via PHP and not in other cases (that makes for example the newest IE UXSS which is not yet patched by Microsoft exploitable on ownCloud)
3. Some headers such as the Strict-Transport-Security might require custom modifications by administrators. This was not possible before and lead to buggy situations.

This pull request moves those headers out of the PHP code and adds a security check to the admin settings performed via JS.

This change will log all failures that prevent the CLI cronjob from happening to the database and display a warning to administrators when an error happened.

To test:

1. Configure some invalid CLI php.ini settings
2. Enable the CLI cronjob and run php cron.php
3. See the errors printed and also in the admin page
4. Configure the CLI settings correctly
5. Errors should be gone.

Fixes https://github.com/owncloud/core/issues/13994

This reverts commit 6a1a4880.

Nobody reads the warnings anyways and so we should enforce it at installation time... Also allows us to get rid of some duplicated code.

To test change the `default_charset` to something other than `utf-8` or `UTF-8`, both should work fine with that change here. An error should then get shown.

We already set those default charsets in the shipped .user.ini and .htaccess