Make alt code for gets() / fgets() changes

As both Landon and I have been wondering if changing entries to use
fgets() is bordering on tampering with entries I decided to make the
original (sometimes bug fixed) versions (using gets()) alt code. I had
originally started to make the fgets() version of each entry the alt but
since the fgets() versions can handle input better and since some also
fixed bugs (see below) I decided to make the original version the alt
code (this also is how it is for other entries).

There were some exceptions here. If the change also fixed some crashes
or other bugs outside of the gets() to fgets() conversion I did not
bother to make an alt version. An example is 1992/dds. In some cases the
alt code does have bug fixes in which case they were added.

Updated the Makefiles and .gitignore files as well for the alt target
and the new files (compiled and in the case of 1992/adrian additional
source files in the Makefile alt rule).

This should solve the problem observed by Landon and me. It wouldn't be
a problem to change it so the alt version is the one that uses fgets()
but I think that might be the wrong choice.

In some entries I altogether avoided changing to fgets() say if the
author notes it uses gets() (in one case even providing a version that
uses fgets()). In some cases using fgets() introduces a bug so those are
also not changed.

As for 1990/tbr there's a strong reason for not having the fgets()
version being the alt. In macOS in particular (in linux - or maybe gcc,
not sure - it shows a warning at linker time) it will mess up the first
line of output in a potentially confusing way. For instance:

    $ ./tbr.alt
    $ warning: this program uses gets(), which is unsafe.
    # nothing here, what to do?

And that touches on another issue of making the alt version the one that
uses gets(): the warnings that can be alarming during compilation,
linking and (in the case of macOS) runtime.

Not all entries should be or can be changed to fgets() but some can and
it's warranted for these reasons. More will possibly happen in the
future.

1990/tbr/README.md

@@ -15,7 +15,9 @@
 
 ## To build:
 
-        make all
+```sh
+make all
+```
 
 [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this to work with
 modern compilers; `exit(3)` returns void but the function was used in a binary
@@ -24,24 +26,14 @@ expression so this wouldn't even compile. Cody also changed the code to use
 `gets()` at execution which was interspersed with the output. Thank you Cody for
 your assistance!
 
-For the original version with `gets()` see the alternative code section below.
-
-## Alternative code:
-
-If you wish to see the original source (fixed so it can compile) that uses
-`gets()` instead of `fgets()` you can look at [tbr.alt.c](tbr.alt.c). To compile
-it:
-
-	make alt
-
-Use `./tbr.alt` instead of `./tbr` for this version. You'll likely get a warning
-about the usage of `gets()`.
-
+For the original version with `gets()` see the alternate code section below.
 
 ## To run:
 
-	./tbr
-	# enter some shell commands
+```sh
+./tbr
+# enter some shell commands
+```
 
 NOTE: globs do not work with this entry. Why?
 
@@ -61,6 +53,19 @@ or ctrl-c (or kill it from another terminal :-) ).
 What happens if you try using `cd -` to return to previous directory? What about
 `cd` with no args?
 
+## Alternate code:
+
+If you wish to see the original source (fixed so it can compile) that uses
+`gets()` instead of `fgets()` you can look at [tbr.alt.c](tbr.alt.c). To compile
+it:
+
+```sh
+make alt
+```
+
+Use `tbr.alt` as you would `tbr`. You'll likely get a warning about the usage of
+`gets()` and with macOS it will mess up output of the first line.
+
 ## Judges' comments: