Port compatibility changes from 8f5fdab5bf to glitch-soc

Port 5ea643b279 to glitch-soc

Port 46061dc041 to glitch-soc

Port 7403e5d306 to glitch-soc

It should not be necessary thanks to our Content Security Policy, but best
be sure in case a server's CSP is incorrect. Also, avoids a CSP warning about
loading remote scripts.

Port bb5558de62 to glitch-soc

Port 28401962ca to glitch-soc

Port 05f90e3695 to glitch-soc

Port f66a786029 to glitch-soc

Port 7c12c7b124 to glitch-soc

Port 20bb90ced6 to glitch-soc

Port c9cbb8de70 to glitch-soc

Port 61e6275781 to glitch-soc

Port e72db6d9dd to glitch-soc

Port 7901f9f63e to glitch-soc

Port 25f6f41052 to glitch-soc

Port 60df87f6f0 to glitch-soc

Port e0b1e17bd0 to glitch-soc

Port 955d5d36e8 to the glitch-soc flavour

Port cdb101340a to glitch-soc,
but without dropping support for regexp filters yet.

Port 64d7a63f18 to glitch-soc

So far, glitch-soc used history.length to decide whether to call `goBack()` or
go to / in order to not leave the webUI. This made clicking the “Back” button
go to the “Getting started” column instead of going back in the browser's
history when such an action would leave the web UI, but also when:
- The WebUI is refreshed (F5)
- A tab is restored
- The history length reaches its maximum (e.g., 50 in Firefox)

This commit fixes these shortcomings by checking `window.history.state`.
Indeed, we only want to go back in the browser's history when the current
location has been reached from within the WebUI, which only happens via
`pushState` as far as I know. Since browser store the serialized state in
the browser history, this also survives page reload and session restoration.

Port b1938d7853 to glitch-soc

Port cbf97c03bb to glitch-soc

Port 9a1a55ce52 to glitch-soc

Port b0664a5e6c to glitch-soc

Port d9b2f84c92 to glitch-soc

Port c88e12fca6 to glitch-soc