fix links in entry HTML files other than index.html

Fixed internal links in entry HTML files other than index.html.

Removed links to markdown files that otherwise used to
generate HTML files other than index.html.

Ran `make gen_other_html` to perform the above.

2020/ferguson1/bugs.html

@@ -162,7 +162,9 @@ size 10 of course (but in fact if you observe the snake won’t appear to be
 of size 20 yet).</p>
 <p>There probably are combinations that can test these types of things I just
 don’t at this time remember any I might have done.</p>
-<h1 id="the-snake-doesnt-seem-to-be-moving"><a name="stillsnake" href="#toc">The snake doesn’t seem to be moving</a></h1>
+<div id="stillsnake">
+<h1 id="the-snake-doesnt-seem-to-be-moving"><a href="#toc">The snake doesn’t seem to be moving</a></h1>
+</div>
 <p>One way to show this is in full is to set the initial size and growth size to a
 high value; then try each one individually. For example:</p>
 <pre><code>    SIZE=100 ./prog</code></pre>
@@ -172,7 +174,7 @@ When it has reached the full size then the entire body of the snake will
 start to move too (i.e. if the tail isn’t moving it is growing or else paused).</p>
 <p>In several tests I set the initial size to a high value, the max to a higher
 value still and enabled cannibalism and much of the screen was full of the snake
-before it started to move. The <a href="cannibalism.log.md">cannibalism.log.md</a> has some examples of both
+before it started to move. The [cannibalism.log.md][] has some examples of both
 cannibalism and a long snake that didn’t move for most of the game.</p>
 <p>If however you let the snake get to the full size then eat a bug there can
 be a moment of lingering where it appears the snake moves for a few places
@@ -186,11 +188,15 @@ occupied or not.</p>
 <p>Basically if the snake head is moving you can consider the snake to be
 moving or growing and that’s the important point (if you have the default
 status line you can also see the coordinates being updated to show this).</p>
-<h1 id="getch-also-accepts-input-from-some-input-hardware-other-than-keyboards"><a name="getch" href="#toc">getch() also accepts input from some input hardware other than keyboards</a></h1>
+<div id="getch">
+<h1 id="getch-also-accepts-input-from-some-input-hardware-other-than-keyboards"><a href="#toc">getch() also accepts input from some input hardware other than keyboards</a></h1>
+</div>
 <p>On my MacBook Pro the trackpad has actually triggered directions; if I were to
 swipe up and then down the snake would run into itself. I believe this has to do
 with the function call <code>keypad(v, 1);</code> which enables arrow keys.</p>
-<h1 id="size0-is-the-same-as-size1-and-other-oddities"><a name="size" href="#toc">SIZE=0 is the same as SIZE=1 and other oddities</a></h1>
+<div id="size">
+<h1 id="size0-is-the-same-as-size1-and-other-oddities"><a href="#toc">SIZE=0 is the same as SIZE=1 and other oddities</a></h1>
+</div>
 <p>What this means is that for both you will only have the snake head. At this point
 you can safely go back on yourself even without cannibalism enabled. This is
 intentional; a snake size of 0 is pointless but why should it not be playable
@@ -222,7 +228,7 @@ way negative size will force a win.</p>
 head several places until you end up getting to the max size (by way of it
 being unsigned). This isn’t a bug even if it might seem like one. In fact
 this is the basis of the grow/shrink mode of play that I talk about in the
-<a href="gameplay.html">gameplay.html</a> (<a href="gameplay.md">gameplay.md</a> on GitHub) file.</p>
+<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/gameplay.html">gameplay.html</a> file.</p>
 <p>Here’s another thing to be aware of. Let’s say you do:</p>
 <pre><code>    SIZE=1 GROW=-1 ./prog</code></pre>
 <p>How many bugs will it take before you win? In fact it’s two: you would see the
@@ -230,7 +236,9 @@ head twice: the second time once you ‘shrink’ down to size 0; it would then
 that if you get another bug you will be at the ‘max size’:</p>
 <pre><code>    YOU WIN!
     X:81/156 Y:35/41 S:997/997 B:2</code></pre>
-<h1 id="i-was-a-few-places-behind-my-tail-and-i-ran-into-it"><a name="bitetail" href="#toc">‘I was a few places behind my tail and I ran into it!’</a></h1>
+<div id="bitetail">
+<h1 id="i-was-a-few-places-behind-my-tail-and-i-ran-into-it"><a href="#toc">‘I was a few places behind my tail and I ran into it!’</a></h1>
+</div>
 <p>I.e. what happens if you’re growing - for example after just eating a bug - and
 you’re racing towards your tail? If you’re behind it should be fine since you’re
 going the same speed as the snake is, right? Not quite. Because you’re growing
@@ -238,7 +246,9 @@ you might end up running into your tail (depending on how much you’ve left to
 grow and how far away from your tail)! This happened to me once and it surprised
 me and I figured I better note it.</p>
 <p><strong>Remember: the tail at that point isn’t moving yet; the snake is growing!</strong></p>
-<h1 id="with-negative-growth-the-snake-drops-from-the-middle-of-the-body"><a name="middleofsnake" href="#toc">With negative growth the snake drops from the middle of the body</a></h1>
+<div id="middleofsnake">
+<h1 id="with-negative-growth-the-snake-drops-from-the-middle-of-the-body"><a href="#toc">With negative growth the snake drops from the middle of the body</a></h1>
+</div>
 <p>For instance it might look like this (the first line is as it happens, the
 second pointing to where it happens and the third being what’s left after the
 rest of the snake has gone through). Doing <code>SHED=100 SHEDS=-1</code>:</p>
@@ -261,8 +271,10 @@ go there! :)</p>
 that’s how they grow in the wild so it’s a misnomer. The shrinking was only
 ‘discovered’ because it’s an unsigned number but happily it allows for different
 gameplay modes.</p>
-<h1 id="it-looks-like-the-bug-is-in-the-snake"><a name="buginsnake" href="#toc">It looks like the bug is in the snake</a></h1>
-<p>I show a different example in the <a href="crazy.log.md">crazy.log.md</a> file but what defines a coordinate
+<div id="buginsnake">
+<h1 id="it-looks-like-the-bug-is-in-the-snake"><a href="#toc">It looks like the bug is in the snake</a></h1>
+</div>
+<p>I show a different example in the [crazy.log.md][] file but what defines a coordinate
 which the snake occupies? If the snake breaks apart then the only part
 of the screen the snake is occupying is the place which is actually moving: if
 the snake decreases in size by 3 then the three respective characters you can go
@@ -271,7 +283,9 @@ something like:</p>
 <pre><code>    &lt;*oooooooo</code></pre>
 <p>This is because the snake is no longer there: in fact in this run the snake was
 quite a bit lower on the screen and 25 in length.</p>
-<h1 id="on-the-safety-of-the-bug-placement-loop"><a name="bugplacement" href="#toc">On the safety of the bug placement loop</a></h1>
+<div id="bugplacement">
+<h1 id="on-the-safety-of-the-bug-placement-loop"><a href="#toc">On the safety of the bug placement loop</a></h1>
+</div>
 <p>Ilya Kurdyukov shared concern for the loop in the bug placement routine: is it
 safe? What he refers to is that it’s a potential infinite loop. But is it? I
 understand the concern and it’s something I played with a lot to be sure that it
@@ -308,7 +322,7 @@ that 49 is the max snake size. How is this derived and why?</p>
 (<code>playable_rows * playable_columns</code>). I have played with this many
 times and I do not believe there should be a problem. If there is it’s from a
 very poor implementation of rand() and I discuss this in
-<a href="troubleshooting.html">troubleshooting.html</a> (<a href="troubleshooting.md">troubleshooting.md</a> on GitHub).</p>
+<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2020/ferguson1/troubleshooting.html">troubleshooting.html</a>.</p>
 <p>There I also give some test outputs without the cap in place to give an idea of
 when it became a problem (or would have). In short this is known but I do not
 think it will be a problem and I have given resolutions. In any event without