Add GCC and Clang GitHub workflow builds

[pbatard]

Now that ntfs-3g is hosted on GitHub, we can enable CI on the GitHub repository for both commits and pull requests.

[pbatard]

An example of GitHub Actions build (for this Pull Request) can be found at: https://github.com/pbatard/ntfs-3g/actions/runs/1053111129

[unsound]

If I understand correctly this is a github-specific file that if present in the repository would enable a "build-check" to be triggered for each push to the repository?
Can you describe the benefits in more detail... we have such automated checks running already on Tuxera's servers so I'm not sure how useful it would be to use github's resources for the same purpose.

[pbatard]

Thanks for looking into this PR.

The benefits are that, even if you do have your own internal test, anybody who clones the directory and performs some work would have a GCC + Clang build check performed for each commit they apply to their repo. So, in essence, rather than keep the internal Tuxera build test for yourself, you can, in a simple PR, provide such a build test to the community that depends on your work.

This also would mean that anybody who provides a GitHub Pull Request would get a build test performed automatically, which avoids a lot of the usual back and forth of finding that a commit is broke builds for a simple overlooked detail and extra work for you for having to perform such test.

In other words, one advantage of this is to make sure that, when users submit patches through PRs, you would instantly be able to eliminate the following process:

1. User submits patch
2. You test it on the internal Tuxera servers and find there's an issue that breaks the build
3. You go back to the user and tell them that their patch broke the build
4. User submits a new patch again

Plus, at no cost for anyone (except GitHub, really), it does makes at least some of the modern methods of validating software, such as Continuous Integration testing, public, which, for an Open Source project such as ntfs-3g that is depended on by a large number of people, should be seen as a "good thing"™.

There are also quite a few other benefits that I could list, such as, if the Tuxera CI process is not based on the latest Ubuntu as opposed to this one (runs-on: ubuntu-latest), identifying build/breakage issues introduced by distro updates. There's also the fact that, because it's being used by hundreds of thousands of developer, and was very much devised as such, the GitHub build process is very flexible and can be extended in many ways. For instance, if you ever want to expand ntfs-3g to other platforms (e.g. Windows, which is something I did in my NTFS driver branch or other archs, it's a simple matter of adding a new .yml file, or editing the existing ones, rather than have to devise a custom internal process that you'd also then have to maintain, at your own cost. And I could go on, on the possibility of users gifting you additional testing and validation, that you don't have in the internal Tuxera CI, on account that this public CI exists...

[Neustradamus]

@jpandre: Have you seen this PR?