Move CI to github workflows

[cpascual]

Since it does not seem that we will be moving to gitlab soon (#761 ) , I propose to consider replacing travis+appveyor by the new github workflows.

I've experimented with them and they are way more flexible than travis and appveyor (maybe even than gitlab-CI, but that's a different comparison).

Arguments in favor:

• It is based on docker containers (more or less like gitlab-ci, and therefore they may be easier to move if we eventually aandon GH)
• It supports windows, macos and of course linux
• we can keep our credentials and tokens in one sigle place instead of giving them to various different services
• it seems faster than travis and appveyor
• it facilitates modularity and encourages sharing of the CI recipes (similar to gitlab). See, e.g. https://github.com/taurus-org/publish-conda-action
• We are already using it for conda build and deployment

[cpascual]

Note: the taurus_pyqtgraph project is already migrated entirely (tox tests, flake tests, pypi deployment and conda deployment) to GH workflows, and everything seems simpler and faster.

The structure of the tests of taurus_pyqtgraph is quite similar to that of taurus, so much of the work is already done, but there are a few points that will need investigating:

• in taurus travis we are using the tango service. I think that we can replicate it in GH. In this regard, maybe we can take the oportunity to run TangoTest from the host (since it is provided in the conda package), instead of using a docker. This may solve some issues in the tests due to the docker bridge network blocking events between server and client.
• in taurus_pyqtgraph we use pure tox for the tests, while in taurus we use tox-conda because of pytango. I don't expect this to be an issue, but it needs to be tested
• in taurus we have appveyor (which for us does little in the way of testing, but provides artifacts and builds .msi installers). Ideally we should be able to run full tests on windows (and even mac, except for tango) with the same GH workflow as for linux. But as a first step, we can simply include artifacts in the linux build. Building .msi no longer makes sense since the recommended installation on windows is via conda.
• the documentation deployment to github pages is based on trdoc, which is travis-specific. We need to translate it to GH workflows (I expect some action already existing, such as this)

[cpascual]

One more reason to migrate (either just the CI to GH workflows or the whole project to gitlab): Travis is discontinuing the unlimited CI service for OSS projects:

For those of you who have been building on public repositories (on travis-ci.com, with no paid subscription), we will upgrade you to our trial (free) plan with a 10K credit allotment (which allows around 1000 minutes in a Linux environment). (...) When your credit allotment runs out - we’d love for you to consider which of our plans will meet your needs. We will be offering an allotment of OSS minutes that will be reviewed and allocated on a case by case basis. Should you want to apply for these credits please open a request with Travis CI support stating that you’d like to be considered for the OSS allotment.