Add the versioning possibility to documentation about exonum-doc HOT 3 CLOSED

I envisioned it a little bit differently:

• Each build builds a single documentation version, which is specified by the latest commit
• If the build is on master and (possibly) satisfies other certain conditions, the built pages are deployed using Travis's deploy hook to the /doc/latest or a similar directory (note that naturally, the deploy stage isn't executed for pull requests)
• If the build is tagged, the pages are also deployed to the /doc/$TRAVIS_TAG directory (e.g., /doc/v0.2)

The only thing that's left is configuring mkdocs to work properly with this setup, which includes at least:

• Specifying the base URL so it matches the deployment
• Adding a widget with the version selector (e.g., to the footer). In the simplest case, a list of available versions could be manually specified in mkdocs.yml

from exonum-doc.

@slowli, anything will be good. Just wanted to state that we need to support multiple versions of documentation.

from exonum-doc.

So, a slight elaboration on how I imagine things are going to work:

• There are branches for this repo corresponding to minor versions of the core repository (i.e., v0.1, v0.2, ..., v1.0, ...) in addition to master.
• master corresponds to the latest version.
• These branches can be target of PRs. This may be the case if we forgot (or didn't have time) to document some feature, discovered a bug, etc. In general, though, PRs target master as usual.
• Commits from a PR can be backported to the relevant version branches if deemed necessary. It can be signaled via a special tag on the PR (say, "needs backport").
• During CI builds, the deploy step can determine the branch being built via the TRAVIS_BRANCH environment variable and push the built documentation accordingly. v<something> can be pushed to the <something> dir, and master to the latest dir.
• Note that since TRAVIS_BRANCH influences the location of the documentation, this location should be edited into site_url in mkdocs.yml. This can be accomplished via sed. A minor question is whether it should be done when testing the docs, or only during deployment.
• If we decide to use GitHub pages, the gh-pages branch should be checked out before deployment, then the relevant dir in it overwritten by the generated docs, and then the resulting dir pushed back to gh-pages. (We don't want to erase all other branches.) Seems a bit sketchy but certainly feasible.
• If we use scp or something like it, just pushing the built docs to the relevant remote dir seems to work fine.

Why not tags for versioning? Because we can miss something, so we'll inevitably have to amend documentation pinned to releases.

Do we need tags at all? Maybe; your suggestions appreciated.

cc @djsatok @boguslavsky @defuz

from exonum-doc.