Add GitHub Actions workflow

[umarcor]

In this PR, a GitHub Actions workflow is added. After each push or pull request, the spec in src/b3 is built with sphinx to html and latex, and a PDF file is generated from latex sources. Last, all the artifacts (html, latex, doctree and PDF) are made available. See example run: https://github.com/umarcor/wishbone/commit/8e554f5db621aa756babf8985bbd09f0b7c374d3/checks?check_suite_id=260118245

GitHub Actions seems not to be enabled for fossi-foundation. See https://github.blog/changelog/2019-10-01-auto-admission-in-the-github-actions-and-github-package-registry-beta/

This PR might be enhanced by adding a step to push html build artifacts to branch gh-pages, so that the spec is available at fossi-foundation.github.io/wishbone. In order to enable it, a deployment key can be generated and added to the settings of this repo.

[wallento]

Interesting, currently it is integrated with read-the-docs (https://wishbone-interconnect.readthedocs.io/en/latest/), but I will look into it right now.

[umarcor]

Oh, sorry about that. I didn't find any reference to RTD in this repo, so I assumed such a solution didn't exist. It might be useful to add a badge to the README.

Both solutions, RTD and GitHub Pages, are equivalent. Advantages in favour of GHA are that less layers are involved, so the overall setup is less complex to maintain (users, accounts, tokens, etc.); and a more open framework is provided, which allows for customization of the build. Conversely, RTD is already setup and it works; plus, an open source project is partially funded through ads.

A relevant issue/difference, is that RTD injects JavaScript code in the HTML template. Therefore, documentation might not be properly browsable by users that do not enable it (https://www.mediawiki.org/wiki/No-JavaScript_notes). A custom alternative might solve this. I didn't add any specific solution because currently there is a single version.

[umarcor]

@wallento, any update on this?

I think that having GHA build the assets would be useful to review PRs such as #17.

Apart from that, I saw that you added and suggested using a custom Docker image (cb5a9b0), instead of using the external ones in this PR. I am ok with modifying this PR to use the internal image. However, I think that building the image in each job is not a good approach (installing texlive takes quite long). I can add another workflow to build the docker image and publish it to some registry. The registry can be hub.docker.com (I'd need you to set up two secrets in this repo) or GitHub's package registry (the default GITHUB_TOKEN will work, but images will not be available without authentication). Please, let me know your thoughts.

[umarcor]

ping @wallento