Test flatten option

[rw1nkler]

This PR adds the basic tests for the flatten option in the verilog-diagram directive. The test consists of the Sphinx run in which the module black boxes should be resolved (with the flatten option) for all types of diagrams. The example uses the full adder circuit, which consists of two half adder modules.

In order to get the possibility of checking the output HTMLs, I created the next Travis CI job. The job generates the HTMLs from all test runs, converts them to the single HTML file using monolith and adds them to the GitHub Pages. The Travis setup requires GitHub token with the public_repo access rights. The token should be added as a Travis environment variable with the GITHUB_PAGES_TOKEN name.

Preview of the GitHub pages setup can be found here:
https://rw1nkler.github.io/sphinxcontrib-verilog-diagrams/

The GitHub Pages functionality has been moved to #58

Here is the flatten test preview:
https://rw1nkler.github.io/sphinxcontrib-verilog-diagrams/test_flatten.html

Resolves: #3

---

#52 should be merged first

[mithro]

Rather than using travis, could we just use readthedocs here?

[rw1nkler]

Rather than using travis, could we just use readthedocs here?

I wanted to run the same file with multiple sphinx configurations, which is hard to achieve on readthedocs. In example, this would allow testing the extension with diagrams format (global setting) set once to png and in the second time to svg. The GitHub pages have the disadvantage that the result will be visible only after merging the changes, which is not that useful for testing. But Travis can be integrated with Google Storage for storing artefacts (here the test HTMLs). Maybe this would be the most flexible approach.

If this does not convince you, we can limit ourselves to one Sphinx configuration and create the second RTD project for tests. This should work fine too and should give the direct preview in the CI.

This PR should be merged after the #52. The previous PR is much less controversial.

[mithro]

Thanks for the explanation!

You can set up github actions which allow for "test deployments" of github pages stuff. I have never done that however...

[rw1nkler]

You can set up github actions which allow for "test deployments" of github pages stuff.

I've checked the GitHub Actions available in the GitHub market, but it seems that none of them offers the test deployment functionality. This might be related to the GitHub pages limitation - it only allows for publishing one version of the website.

[rw1nkler]

I believe that we should create a Kokoro setup or upload the artifacts to i.e.symbiflow-scratch bucket with Travis CI.
@mithro What do you think about this problem?

[mithro]

I think pushing to github pages is fine. I'm pretty sure we don't need to use monolith though?

[mithro]

@rw1nkler Can you also split the CI change from the other changes?

[rw1nkler]

@rw1nkler Can you also split the CI change from the other changes?

I have created a second PR with the GitHub pages deployment (PR #58)

[mithro]

This is going to need a rebase now.

[rw1nkler]

@mithro I rebased the PR