Improve/Simplify Https-Everywhere Onion Name Implementation

Fixes #40010 (closed).

This brings back all the logic to keep track of whether we should show an onion alias in the urlbar or not. We should if:

1. The page got redirected from a .tor.onion to a .onion (this includes cases where a user clicks on a .tor.onion link).
2. From a .onion page which allowed .onion alias, we navigated to a different, same-origin page (same actual .onion URL).

Unfortunately I was not very successful with the 'simplify' part. I played a bit with the #34225 (closed) approach, but at the end it was not clear to me whether that would result in much simplification (if at all). In many places, a string is passed instead of a nsIURI, so we would still need to pass additional info, as we currently do, to keep state about the onion alias (and whether it's allowed to rewrite the urlbar in a given page). I also felt it was a bit risky to a add a new string member to all nsIURI subclasses, given that this would only be used in very few cases, but it would have implications on how these are serialized, perhaps backward-compatibility issues.

So, at least for now I decided to keep the patch as close as possible to the one currently in ESR68. Some differences:

• Now the right click -> open link in new window case is handled, to keep the onion alias urlbar if needed.
• Now the case of left click link to same .onion is handled in nsDocShell::InternalLoad, by looking at the referrer.
• I needed to listen to redirects in DocumentLoadListener, since there were cases those redirects were not seen in nsDocShell.
• I changed many allowOnionUrlbarRewrites to onionUrlbarRewritesAllowed. The reason is that there were some assumptions made by Firefox tests (see browser/components/sessionstore/test/browser_capabilities.js | all flags set to true) wrt to docShell.allow*, which were failing with docShell.allowOnionUrlbarRewrites.
• Minor changes in OnionAliasStore.jsm, e.g. to not throw an error so that Firefox tests pass.