Add filtering for custom URI schemata (e.g. mailto:, skype:) to the filterClickEvent to force these to open outside the sandbox

[Jaifroid]

It turns out that attempting to open a mailto: link in a Chromium extension (or in a PWA in Chromium browsers) is seen by Chrome as an insecure protocol, which triggers sandbox blocking. See kiwix/libkiwix#1138. In Zimit1, the ReplayWorker handled this kind of stuff, I think, but we may have to handle it ourselves. There's currently already such a filter in JQuery/Safe mode.

However, we should first try a simple fix by adding mailto: as an allowed protocol in the sandbox Content Security Policy.

[Jaifroid]

According to my tests, relaxing the CSP on the iframe by adding mailto: in the list of exceptions should do the job. In the PWA, I had to add this to the specific frame-src CSP list. See also kiwix/libkiwix#1090.

[Jaifroid]

Having experimented with this in the PWA, I now think we should deal with all such cases generically. We will need to add exceptions for javascript: and about:, but I think everything else, e.g. ftp: (deprecated), blob:, data:, file:, and custom URIs such as zoomus:, skype:, etc. should just be dealt with in the same way: open a new window and let the browser deal with these as it sees fit.

We might add an exception also for data: images, though I'm not sure. Is it useful to open an image inside the iframe in this way (technically that isn't a problem)? Arguably more useful to have it in a separate tab or window, and then the user can right-click it, save it to disk, print it, etc, without the iframe getting in the way.