Format / typo check YYYY/README.md files

It should be pointed out that there are a few inconsistencies as noted
below.

In some years the title of entries that were explicitly listed were
linked to but as the README.md files no longer have the title it was not
as easy to locate the title (I could go back in archive/historic and I
did in some cases but I was trying to hurry this up to close #3).

It's most likely that some have backticks surrounding certain words like
gcc or something else but not in all files. An example that might be
there is '#define'.

Some wording is different. Usually this is due to the original wording
which I did not think was good to change. There might be other cases
that were missed as well. One thing is that comes to mind is that in
some README.md files it refers to the Makefile to check for build
instructions, in others it refers to the index.html file and in some it
refers to both. But the index.html has how to build so they should
probably all say index.html and not refer to the Makefile. This was also
done in a rush.

There might be other inconsistencies or things that might want to be
fixed but whether it's worth it given is unclear at this time. It can be
argued that the reference to the Makefiles for build instructions is a
historical comment to keep there as an example of why not to change it.

There were other things I noticed that I could not address or did not
feel were necessary but with this commit an important task is can likely
be considered done unless it is decided that some of these should be
fixed or if looking at the rendered output there is a problem.

2018/README.md

@@ -6,7 +6,8 @@
 View the `index.html` web page for the given winning entry for information on how
 compile the entry and how to run the winning program.  Look at the winning
 source and try to figure how it does what it does!  You may then wish to look at
-the Author's remarks for even more details.
+the Author's remarks for even more details. This year we included most of the
+information included by the submitter.
 
 The primary site can be found at [www.ioccc.org](https://www.ioccc.org).
 
@@ -14,12 +15,11 @@ Use `make` to compile entries.  It is possible that on non-Unix / non-Linux
 systems the Makefile needs to be changed.  See the Makefile for details.
 
 Look at the source and try to figure out what the programs do, and run
-them with various inputs.  If you want to, look at the hints files for
-spoilers - this year we included most of the information included
-by the submitter.
+them with various inputs.
 
-Read over the Makefile for compile/build issues.  Your system may require
-certain changes (add or remove a library, add or remove a #define).
+Read over the Makefile and index.html files for compile/build issues.  Your
+system may require certain changes (add or remove a library, add or remove a
+`#define`).
 
 Some C compilers are not quite as good as they should be.  If yours is
 lacking, you may need to compile using clang or gcc instead of your local
@@ -30,24 +30,24 @@ compiler.
 
 We believe you will again be impressed with this year's winning entries.
 
-The "Best of show" (mills) is an amazing tribute to entrues
+The ["Best of show" (mills)](mills/index.html) is an amazing tribute to entries
 from 1984 and 2015.
 
-Take a close look at the "Most likely to top the charts" [2018/hou](hou/index.html)
+Take a close look at the "[Most likely to top the charts" (hou)](hou/index.html).
 Observe that while it contains no variables and no operators, it
 remains functional in what it does.
 
-The "Best one-liner" (burton1), at 109 characters, is a short and sweet
-implementation of a classic utility and a nod to a winning entry from 1986.
-Sometimes it takes 20 ox years to do things the true IOCCC way.
+The ["Best one-liner" (burton1)](burton1/index.html), at 109 characters, is a
+short and sweet implementation of a classic utility and a nod to a winning entry
+from 1986.  Sometimes it takes 20 some years to do things the true IOCCC way.
 
 The color of the remarks text this year was inspired by one of the stars
-of the "Most stellar" [2018/poikola](poikola/index.html).
+of the ["Most stellar" (poikola)](poikola/index.html).
 
-The "Best use of python" (endoh2) is a not what you might think it is.
+The ["Best use of python" (endoh2)](endoh2/index.html) is a not what you might think it is.
 It is something completely different.
 
-The "Most likely to be awarded" (ciura) has an amazing vocabulary!
+The ["Most likely to be awarded" (ciura)](ciura/index.html) has an amazing vocabulary!
 
 There are also nods to entries of the years [2000/bellard](2000/bellard/index.htmk),
 [1989/yang](1989/yang/index.html), ...
@@ -63,21 +63,23 @@ and 22 (one third of 666).
 
 Rule 22, now known as "Catch 22" states:
 
-    |  22) Your source code, data files, remarks and program output must NOT
-    |      identify the authors of your code.  The judges STRONGLY prefer to
-    |      not know who is submitting entries to the IOCCC.
+```
+|  22) Your source code, data files, remarks and program output must NOT
+|      identify the authors of your code.  The judges STRONGLY prefer to
+|      not know who is submitting entries to the IOCCC.
 
-    |      The "Peter Honeyman is exempt" guideline also applies to this rule.
-    |      Identifying yourself, in an obvious way in your code, data, remarks
-    |      or program output, unless you are Peter Honeyman or pretending
-    |      to be Peter Honeyman, will be grounds for disqualification of your entry.
+|      The "Peter Honeyman is exempt" guideline also applies to this rule.
+|      Identifying yourself, in an obvious way in your code, data, remarks
+|      or program output, unless you are Peter Honeyman or pretending
+|      to be Peter Honeyman, will be grounds for disqualification of your entry.
+```
 
-A number of other entries were based on iocccsize.c, making derivative works
-rather than original works.
+A number of other entries were based on [iocccsize.c](iocccsize.c), making
+derivative works rather than original works.
 
 Still other entries were too large, violating the first line of rule 2:
 
-    2) The size of your program source must be <= 4096 bytes in length.
+> 2) The size of your program source must be <= 4096 bytes in length.
 
 While these entries might have passed under the 2053 limit for iocccsize,
 they were larger than <= 4096 bytes, sometimes by an order or magnitude.