Add GO REFs page

[pkalita-lbl]

Fixes #506

Summary

These changes add a Makefile with a target to fetch the latest gorefs.yaml file from the go-site repo. From this file a single GO REFs page is generated.

Details

• Add a Makefile with a single target, _data/gorefs.yaml, which fetches the latest gorefs.yaml from the head of the master branch of the go-site repo.
• Add the _data/gorefs.yaml file to .gitignore. This file will never be checked into this repo to maintain go-site as the source of truth. The Makefile target should be run before doing any development or making a production build.
• Add a single gorefs.html page which lists all GO REFs. The format of this page is largely based on the existing README file (https://github.com/geneontology/go-site/blob/master/metadata/gorefs/README.md). One notable difference is that this page does not include the "table of contents" at the top of the page. It wasn't clear how much value that really provides. Each GO REF title links to its own page anchor (e.g. /gorefs#GO_REF:0000008).
• Add an index page at gorefs.html which lists the ID and title of each GO REF. This is modeled on the "table of contents" at the top of https://github.com/geneontology/go-site/blob/master/metadata/gorefs/README.md. Each item links to a separate page for the individual GO_REF. Based on feedback in Get feedback on current new go_refs page go-site#2255, obsolete GO REFs are listed in a separate list at the bottom of the page.
• Add individual pages for each GO REF (e.g. gorefs/go_ref0000003.html)

Screenshots

Index page:

Individual GO REF page:

Comments

• As mentioned, the new page currently only surfaces the same information that the old README file did. In particular the following fields are part of the GO_REF YAML file specification, but not displayed on the page: alt_id, evidence_codes, url. If we want to take this opportunity to display that information we could.
• You'll notice that plain URLs don't render as links in this page, whereas they did in the README (as displayed on GitHub anyway). This is due to a difference in the Markdown renderers used by GitHub vs Jekyll (further reading here and here). I can keep looking at technical solutions to get them linked. But if all else fails the descriptions may need to be updated to enclose the URLs in angle brackets (<http://example.org>).
  UPDATE: Jekyll's Markdown renderer does not turn plain URLs into links, which are somewhat pervasive in the GO REF descriptions. I added a custom Liquid filter to turn these URLs into links.
• I talked briefly with @kltm about one long page vs individual pages for GO REFs (or both) and decided to do one long page with anchor links for now. However I'll throw out the standard caveat that anchor links can be a little confusing for sections near the bottom of the page (i.e. when there isn't enough content below the desired section to scroll it all the way to the top of the view).
  UPDATE: After feedback in Get feedback on current new go_refs page go-site#2255 we reversed course and did make an index page and individual pages.

[kltm]

@pkalita-lbl Technically, this should never be an issue as it's handled automatically, right?

[pkalita-lbl]

Automatic in the production build and deploy workflow, yes (as outlined in #507). It's not as easy to automate it for a local development environment. I looked into ways to hook into Jekyll's build process to make it fully automatic, full stop, but it felt a bit like overkill. In the end I figured that requiring a developer to run one make command if they want to work on that page isn't a bad compromise.

[kltm]

Makes perfect sense--I just wanted to make sure we weren't going to panic Suzi.

[kltm]

All changes make sense to me.
Can be merged with switchover coordination.

[pkalita-lbl]

Thanks for the review. My plan is to wait for the initial feedback from geneontology/go-site#2255 before merging this.

[pkalita-lbl]

@kltm I pushed some changes in accordance with geneontology/go-site#2255 and updated the PR description/screenshots. Do you want to give this one last glance before I merge?

[kltm]

Looking at your changes, I still approve.
@pgaudet If you look at the images above, is this sufficient?

[kltm]

@pkalita-lbl , talking to @pgaudet , she said that she's good to move ahead.