WIP: Build tests nightly

[seisman]

Description of proposed changes
IMHO, we still need to run tests to make sure that changes don't fail the test. Before #53 is solved, at least we can running the test nightly as a temporary fix.

Reminders

• Make sure that your code follows our style. Use the other functions/files as a basis.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Describe changes to function behavior and arguments in a comment below the function declaration.
• If adding new functionality, add a detailed description to the documentation and/or an example.

[joa-quim]

There is no point in setting up the tests. Aside from the duration issue, we know for sure that they will fail. They will fail for two main reasons. One is that there are true failures. The other is that they currently are MACOS centric and when when run from Linux we’ll see many new failures due to tinny differences in PS.

We talked about this before, what we really need is to be to run code coverage to see what our test set does effectively tests. I believe that when we do it we can drop several tests ad find that we have adapt others. The problem is that making coverage of C code is not obvious, but GDAL is doing it. So it must be doable.

[PaulWessel]

We need to discuss the purpose of the tests and better ways to arrange them . Joaquim is right that running all is not that helpful. Coverage is important and maybe a topic for discussion in Faro. Splitting the tests up is also needed, especially if we increase their numbers.

[seisman]

@PaulWessel @joa-quim OK, I'll close the PR.

BTW, the C code coverage seems straightforward with gcov and codecov.

[joa-quim]

I tried gcov once but didn't have much success (or was it gperf?). But more than 15 min in unix start to give me head-aches so I gave up easily.