Use generic event listener for link processing

[Jaifroid]

This is point 1 discussed in #725. Rather than a new feature for jQuery, I see it as code cleanup, and it will prevent seeing so many "violations" for adding non-passive event listeners to hundresds of document links that show up in the Chromium console. Instead, we add a single onclick event listener on the iframe's contentWindow. Then we use almost exactly the same code as we currently have to analyse the clicked link. So changes would be minor.

It's the same solution as proposed for Option 2 of #404, except that of course for SW mode the function would only intervene if the user has clicked a link that navigates away from the document. The code for this could be re-used between both modes, or not used at all for SW mode if it is determined not to be safe.

I did bash together a prototype yesterday (it only took 15 minutes) as a quick test for how Option 2 of #404 would work, but if not used there, the same principle can be used for this PR. It is in branch Check-for-external-links-and-warn and only works in SW mode to check for external links and asks the user if they want to access the site. It can be used for testing the viability of #404, but also for testing the principle of this PR before writing any more code.

[Jaifroid]

As discussed at the Hackathon, we may be forced to apply some link processing in SW mode to enable opening external links in a new tab or window. The method outlined above (minimized for the single requirement of opening external links) could be used for this purpose.