[meta] Replace http urls with https urls of the respective sites in core

We don't modify vendored code.

Yeah, I don't think #5 was about our code having links to third party websites. It was about modifications in assets/vendor, which is vendor code that we directly copy into our repo. Those files should not diverge from the vendor versions.

Yes, let's re-scope this into small, easier to review issues. Ideally, the scope is by the type of fix which makes it much easier for reviewers. I haven't looked closed enough but it may be possible to have an issue for user facing strings, one for comments, one for tests, and one for production code. I did see there are a lot of changes to .svg files, which could be a separate issue. So, this issue could be the Meta with children. And when, the children are fixed this could be used to fix any stragglers that have crept in to the code base.

Some other thoughts
1. Any ideas on how to prevent 'http:' in the future
2. Are there tests that are specifically testing http that should not be changed?
3. the migrate test fixtures drupal6.php and durpal7.php are not to be changed.

For lack of my 7am brain being able to come up with a clever way to do this in bash, running

<?php
$f = fopen("5278.diff", "r");
$regxp = "/https:\/\/([a-z0-9A-Z\.-]+)[^a-z0-9A-Z\.-]/i";
$matches = [];
$results = [];
while (!feof($f)) {
  $line = fgets($f);
  if (preg_match($regxp, $line, $matches)) {
    $results[$matches[1]] = isset($results[$matches[1]]) ? $results[$matches[1]] + 1 : 1;
  }

}
array_multisort($results, SORT_DESC);
foreach ($results as $name => $count) {
  echo $name . ": " . $count . "\n";
}

on the original MR gives

example.com: 1412
www.w3.org: 747
www.example.com: 136
jsonapi.org: 77
jqueryui.com: 58
jquery.org: 48
www.drupal.org: 40
api.jqueryui.com: 37
drupal.org: 22
www.test.com: 20
wikipedia.org: 18
google.com: 14
docs.jquery.com: 9
www.doctrine-project.org: 8
fonts.fontprovider.com: 8
php.net: 7
www.sqlite.org: 7
en.wikipedia.org: 7
api.drupal.org: 7
www.collegehumor.com: 7
symfony.com: 6

along with ~80 additional domains with < 5 usages

The numbers are a bit off from the actual work between codebase changes and the vendor changes to be undone. Also the xmnls in the svg files should not be changed, https://www.w3.org/2000/svg is an identifier, not a url, and it should not be https. Still probably a good baseline to start with. Having discussed scoping child issues of metas like this several times with @xjm in the recent past, I'm fairly confident we should be doing this by domain for the top domains and then catch the one-offs in a separate issues or issues as it makes sense. These are probably not novice issues (at least not all) as there are many places where this should not be changed at all. Let's start with a child issues for

example.com: 1412
www.w3.org: 747
www.example.com: 136
jsonapi.org: 77
jqueryui.com: 58
jquery.org: 48
www.drupal.org: 40
api.jqueryui.com: 37
drupal.org: 22
www.test.com: 20

and go from there. We can also probably standardize on replacing http://www.example.com with https://example.com and http://drupal.org with https://www.drupal.org while we are at it.

As far as preventing reocurrances, I think we will have to turn to phpstan or codesniffer, and I'm not 100% sure which is better, but I would expect it is codesniffer.

@mikelutz, thanks for the script and the numbers. Doing this by URL makes sense to me now.