Remove legacy PHP 5.3 code from PhpMail plugin

Rerolled with git rebase, which automatically moved the the PhpMail stuff to the new location.

Found another example of safe_mode checking in ArchiveTar.php

+++ b/core/lib/Drupal/Component/Archiver/ArchiveTar.php
@@ -182,7 +182,7 @@ function loadExtension($ext)
-            if ((ini_get('enable_dl') != 1) || (ini_get('safe_mode') == 1)) {
+            if (ini_get('enable_dl') != 1) {

This is Component code, we shouldn't change it. See #1298304: [Meta] Move all externally-developed files to core/vendor/{vendorname}/ directories

Every few months, however, someone comes along and submits an issue to apply current coding standards to these files, which wastes time and energy for all concerned.

Oops. Thanks, I had assumed that everything was already under the vendor directories.

Is there any risk of running into 5.3 code that would actually fatal under 5.4 in any of the Component or vendor directories? This was the only thing revealed by a phpstorm language level inspection of the whole codebase, so my hunch/belief is that there shouldn't be any problems.

Also, apparently the file in question isnt *totally* a component.

#1669896: Please clarify status of ArchiveTar.php

#1 is RTBC, in any case.

Thanks. But:

1) Let's reupload #1 to make sure it's the most recent one so that a core committer doesn't accidentally commit the wrong one.
2) The patch does less than what the issue title and summary say. Let's either continue to add more to it, or else if we want this committed on its own, retitle and resummarize this issue and open a new meta to track what else there is.

If there's any sensible use-case for hiding attached issue files at all, then I guess this is it. And to be extra sure:

Patch to commit is #1

Adjusting issue title accordingly. Adding new "PHP BC cleanup" issue tag, because it does not make sense to attack all affected code in a single issue/patch.