upgrade URLs to HTTPS, remove exec flags

[vszakats]

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused (add your cask's name to the end of the search field).
• Checked the cask is submitted to the correct repo.
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

This mainly aims to fix the regression for the insecure link introduced for VMware Fusion 13.5.2. Then also run my old URL upgrader script (that I used here in the past) on the whole repo and bumped other insecure links that have secure alternatives.

[bevanjkay]

Thank you for opening this @vszakats - looks like CI has picked up an issue with font-titillium and windterm.
Also, PRs should be split to have one commit per Casks/Formula to keep the history cleaner.

[vszakats]

Thanks, I'll be looking at the two fallouts, but breaking this into ~35 PRs is probably something out of my capacity. We used to handle these in batches back in the days, mainly not to overload Jenkins.

[bevanjkay]

As mentioned in the other PR, we aren't asking for one PR per formula/cask, but one commit per formula/cask.

[vszakats]

Regarding the fallouts, they both seem pre-existing and not caused by this PR.
In case of font-titillium I'm having a hard time understanding the problem; the pre-existing download works correctly (when checked manually). It might need a customized livecheck?
As for windterm, the version referenced doesn't exist anymore.
I could probably upgrade, but mixing in upgrades into this doesn't seem like a prudent thing to do.

Maybe dropping both from this PR is the best, even though this PR would still improve their state despite their existing issues. What do you think?

[bevanjkay]

We can't merge when CI is ❌, so splitting to another PR is probably best in those cases.

[vszakats]

OK, split to one commit per file and dropped the two broken ones.