Switch from SonarCloud to Coveralls and maybe Codacy

[egpbos]

SonarCloud needs a sonar-project.properties file in the root directory, which hurts my eyes real bad (related to #120). No other coverage tool needs such an intrusive root-level file. I vote we switch to Coveralls for coverage logging and perhaps Codacy for code-quality.

Coverage can then just be handled from the build Actions workflow, without needing a separate file. Also, we can get rid of the SonarCloud workflow.

I'm a bit in doubt about Codacy for code quality, because we already run a lot of linters and I don't think Codacy does much more than that. Especially if we were to switch to strict linting (see #87), I think there's nothing Codacy would add.

[cwmeijer]

I'd imagine that Codacy does some more complex checks as well that I wouldn't consider just linting. For instance tracking the number of variables simultaneously in scope or complexity of a function etc. I just had another look at our sonarcloud project page and it isn't very inviting and I found zero points to improve there. Basically another argument to switch to Codacy, which has always worked fine for me. +1 for coveralls and codacy

[egpbos]

With strict linting, you get those complexity checks etc as well in pytest. We could do them in Codacy instead of setting linting to strict, though.