Sunset gh-pages in favor of new master

[janbrasna]

Since conf tool is moved elsewhere, there's no need to build any new github-pages here. That gives us chance to start cleaning up a new default branch, say master or main, based on the gh-pages, but then going disjunct ways (default can purge legacy links that won't get (un)published anywhere; while gh-pages can contain legacy redirects and historic json specs working…), to make it crystal clear this repo now houses only current wiki pages, no legacy technicalities that can stay frozen in place out of sight…

1. gh-pages will be kept for legacy purposes, to build redirects et al. to the now-unused deployment to github-pages +to keep all original links to raw/blob/tree files intact as these have gh-pages branch name baked in…
2. new master can be made more accurate reflecting what's the repo content these days, with no legacy content present just to make old urls working.
3. this enables the cleanup of master as all the subfolders +icons etc. can be gone now — as master is for updates to *.mediawiki only; and on the other hand the gh-pages branch can have the *.mediawiki files removed so they stop being deployed to github-pages where they don't most likely belong.

OQ:

• are *.mediawiki files published to github-pages for a reason? how they get to the wiki? manually? or via the github-page url somehow? i. e. if their gotoprod path is not via the gh-page, than this could be pruned to strictly separate uptodate content from legacy shims.
• are the aws/bucket assets for ….tls.sec….mozilla.org pulled automatically or manually? i. e. if nobody publishes them, they stay at the current version? if there are any build scripts, those point to gh-pages branch? then we can have default/master with uptodate content without caring about the legacy deployments as well.