Extend aliases and add .mdoc as a supported Roff extension

[Alhadis]

This PR adds .mdoc to GitHub's list of Roff extensions, and adds several aliases to make tagging fenced code-blocks easier.

Description

The .mdoc extension was brought to my attention by github/markup#1196, and I was surprised it was missing. In-the-world usage is in the neighbourhood of 9,374 results. The sample being added here is taken from libzip, released under MIT.

In addition, I've added several commonly-used synonyms for Roff to facilitate the tagging of fenced code-blocks on GitHub. There's a good chance users might use ~~~man or ~~~groff without knowing the correct name/spelling.

I've also replaced .man with .roff as the language's primary extension. Roff doesn't have a canonical file extension, but if it did, .roff would make more sense than .man. =)

Checklist:

• I am associating a language with a new file extension.
  • The new extension is used in hundreds of repositories on GitHub.com
    • Search results for each extension
  • I have included a real-world usage sample for all extensions added in this PR:
    • Sample source(s)
    • Sample license(s)

/cc @jordemort

[pchaigno]

LGTM!

[lildude]

LGTM

[Alhadis]

I wonder why GitHub allows self-assignment to merged/closed pull-requests...

Moreover, I wonder why the hell I'm noticing this, let alone writing about it.

[RalphCorderoy]

If roff has a canonical file extension then I'd say it's .tr originating historically to indicate troff-compatible input versus troff's predecessors.

[Alhadis]

@RalphCorderoy Yes, but unfortunately, the .tr extension has very little usage in-the-wild; and that's a binding factor when determining which extensions we can and can't register on GitHub. =)

My point was that there isn't a canonical extension, but .man probably isn't the best compromise... 😕

[RalphCorderoy]

So it's a land-grab of file extension, first takes all? Or more than one thing can say .foo might be theirs and they all get to have a closer look? For finding man pages, a search for ".SH NAME" and/or ".SH SYNOPSIS" would seem suitable, but I had no luck getting GitHub to want both words on the same line, in that order, with only mandatory white-space separating them.

[Alhadis]

See CONTRIBUTING.md. =) It pretty much explains the prerequisites; and yes, to some extent, I'm afraid it is largely down to a popularity contest, so to speak...

Think of it this way: GitHub certainly don't want to be indexing literally every single file-extension that has less than a hundred uses, and that's where they'd find themselves eventually. If every user felt their hobbyist side-project-programming-languages were eligible for registration on GitHub, think of the mess we'd find ourselves in. 😉 It'd be an endless deluge of conflicting extensions and misclassifications as the Bayesian classifier struggles to cope with 430 .gs extensions that were used about 10-30 times on GitHub.

I'm not site staff, so I don't claim to know the exact reasoning behind their prerequisites... but if I were in their shoes, I'd be doing the same thing. A line has to be drawn somewhere.

[pchaigno]

So it's a land-grab of file extension, first takes all?

To complete @Alhadis's answer, several languages can be associated to the same extension of course. Even if we associated extension .stuff only to language X in the past, language Y can be associated to .stuff at a later time. Both languages will have to meet the prerequisite @Alhadis mentioned of course.

[Alhadis]

I feel legitimately guilty right now.

Poor @RalphCorderoy is left thinking .tr isn't important or popular enough to become a first-class citizen, and here I am preparing a PR to get FIglet fonts added to GitHub. 😅

And, uh, 3-4 other font-specific text formats I smashed out grammars for.

I should be designing fonts instead of ruining @lildude's week...