Rename: hiw-gibbons -> hiw-gibbon

The compiler's name is 'Gibbon', not 'Gibbons'

Author: Yuji Yamamoto

…img/2019/hiw-gibbons/tree-and-array1.svg …/img/2019/hiw-gibbon/tree-and-array1.svgpreprocessed-site/img/2019/hiw-gibbons/tree-and-array1.svg renamed to preprocessed-site/img/2019/hiw-gibbon/tree-and-array1.svg preprocessed-site/img/2019/hiw-gibbons/tree-and-array1.svg renamed to preprocessed-site/img/2019/hiw-gibbon/tree-and-array1.svg

@@ -23,11 +23,11 @@ Gibbonは最適化の手法を研究するために作られたコンパイラ
 こうした木構造のデータは、通常ポインターを使ってメモリー内にバラバラに格納されますが、Gibbonによる最適化を行うと、実際にプログラムがどのような順番で木を処理しているのか解析して、（元のデータ構造を配列に変換した上で）その順番に並べられた配列として処理するコードに変換する、という大胆な変換を行います。
 図にするとこんなイメージでしょうか？
 
-![変換前の木構造。各ノードがそれぞれ（レベル順で）A, B, ... , Gという値を持っている](/img/2019/hiw-gibbons/tree-and-array1.svg)
+![変換前の木構造。各ノードがそれぞれ（レベル順で）A, B, ... , Gという値を持っている](/img/2019/hiw-gibbon/tree-and-array1.svg)
 
 👆のような木構造があったとして、
 
-![行きがけ順（A, B, D, E, C, F, Gの順）でアクセスする](/img/2019/hiw-gibbons/tree-and-array2.svg)
+![行きがけ順（A, B, D, E, C, F, Gの順）でアクセスする](/img/2019/hiw-gibbon/tree-and-array2.svg)
 
 👆における、赤い線の順番<small>（行きがけ順）</small>にアクセスする関数があったとします。  
 適当にHaskellの再帰関数として書くと、👇こういうコードです。
@@ -66,7 +66,7 @@ preOrder access (Node char mLeft mRight) = do
 
 Gibbonはこの関数と、それが処理する木構造を解析して、
 
-![変換された配列。A, B, D, E, C, F, Gの順に要素が並んだただの配列](/img/2019/hiw-gibbons/tree-and-array3.svg)
+![変換された配列。A, B, D, E, C, F, Gの順に要素が並んだただの配列](/img/2019/hiw-gibbon/tree-and-array3.svg)
 
 👆のような、ただの配列（とそれに対する関数）にまとめて変換してしまう、というのです！