Add tests to github actions CI

[BenjaminRodenberg]

Closes #60

This PR adds tests for different building and installation options. This is especially useful for making sure that we do not break requirements for the spack image (such as the option --single-version-externally-managed).

Failing tests:

• setup_install -> Will be fixed by updating dependencies on develop
• setup_install_single_version_externally_managed -> Will be fixed via Clean-up of setup.py #65

[BenjaminRodenberg]

@fsimonis does the PR look more or less sane w.r.t usage of github actions? I will also open a PR in https://github.com/precice/ci-images in a moment. (edit: see precice/ci-images#1)

[fsimonis]

Wouldn't it be a bit more resource-friendly to run all the installation versions only if the solverdummy test succeeds?

Some additional notes:

• You can give your jobs real names without underscores.
• You may have to use a custom shell when running the actions in the docker container. https://github.com/precice/precice/blob/641e5057cb5d71d39ed43ae1dbc6af597b60bf52/.github/workflows/build-and-test.yml#L20-L22

[BenjaminRodenberg]

Tests finally working. Ready for review.

@fsimonis: Can you quickly check whether everything is "sane" from a github-actions-point-of-view?
@ajaust: Are we missing something important that we need for spack?

[ajaust]

I have added some comments. It is mainly about updating pip when it is installed via the system's package manager.

[fsimonis]

This PR looks good to me.
I suggest to merge it and see how it behaves on develop.
The action can always be tweaked if necessary.

One last idea: would it make sense to define dependencies between the tests to limit the amount of failing ones?

[BenjaminRodenberg]

This PR looks good to me.
I suggest to merge it and see how it behaves on develop.
The action can always be tweaked if necessary.

One last idea: would it make sense to define dependencies between the tests to limit the amount of failing ones?

Yes and no. I like it that all tests are run in parallel and therefore finish after approx. 5 min (longest runtime: build_spack). A long sequential chain of tests will have a longer runtime. I think having "batches" of 2 depending jobs will be a good compromise (first the general one, then the more specific. First setup_install, then setup_install_single_version_externally_managed). I will implement this and then merge.