HTTPS to HTTPS 40 Rules Refactor

[zoracon]

Background:
There were quite a few older rules supporting HTTPS to HTTPS redirects that we generally would like to clean and move towards a safer and more reliable service as an extension.

The Concerns:

• There were some rulesets that had HTTPS to HTTPS redirects, causing the potential shady realm of valid urls being pointed to places they potentially should not
• Some of these rulesets were originally acting as a redirect service for site devs/admins who may not have properly routed their CDNs
• Many of these rulesets come from more older conventions of the encrypted web
• For example:

1. When site devs forgot to add www and proper redirects to the host from www urls
2. secure.example.com urls

Reasoning:

1. The main reason is to truly return to the initial nature of the plugin. And that is to safely port the user from un-encrypted to encrypted connections.
2. Many of the original concerns around bad SSL errors have been addressed with: Disable per site #16546
3. Also, there is a future for the plugin to serve in other capacities. And for that to happen as a reliable source in these plans, we need to work together to make sure the plugin does exactly as intended.
4. This cleaning also reaffirms our promise to the user that the plugin does exactly what it says

Plan

1. I will tag in and reference the original contributors for certain complex rulesets before any changes get merged in
2. As review occurs, I will keep up tests for the rulesets as any changes that may come in
3. After testing, we can move forward to merge

[zoracon]

@Hainish @J0WI @Bisaloo
Above I have explained this PR and the reasoning behind it.

A lot of the original contributors to these rulesets are no longer on Github. So when any of you have a chance, possibly take a look at some of the refactored rulesets that had some further nuance, complicated regex, and rules; I'd greatly appreciate any feedback. I am just making sure i follow typical conventions and documentation

In particular: These files

• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-b039aaa98455f279c1b350b1eccebeac
• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-268dc2564aab70688b761faca97d395b
• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-abee326905ddc5ab2f7b421776f38b97
• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-17be465a3d153dfee09ab4324e038196
• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-d3125a87952a8ae0aea5f37d4eabe66d
• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-cbcc53dfb03a5dbe46ba02b0774f2b7b
• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-65f2ab106fb0c611f539482e0fc1dc0d
• https://github.com/EFForg/https-everywhere/pull/16924/files#diff-1e5c530d14291bc6176f372f318dc5d9

[J0WI]

I did not yet review all files, but here are some things I noticed:

• Is it worth to apply these updates to default_off rules?
• Applying a generic redirect to a rule that contains a wildcard target can have negative side effects (breaking not yet listed subdomains).

[zoracon]

I did not yet review all files, but here are some things I noticed:

* Is it worth to apply these updates to `default_off` rules?

* Applying a generic redirect to a rule that contains a wildcard target can have negative side effects (breaking not yet listed subdomains).

I can definitely go back and leave the ones that were already off. I must admit, I started these changes when I didn't fully get the default off feature, but now I do. So I can condense the PR some for that. I can go back over the rulesets that had wildcards and see what can be amended there as well. Thank you for the feedback.