GitHub Actions: Split test_build workflow in 3

[pierre-guillou]

This PR splits the test_build workflow into 3 sub-workflows, one per platform (Ubuntu, macOS & Windows), similarly to what is done in https://github.com/gstlearn/gstlearn (nonreg-test workflows). The 3 new files should be more manageable that the original one. In particular, it is easier to diff them to spot inconsistencies between the workflows.

The original test.yml workflow has been kept as an entry point. It should be triggered at every PR and commit on the dev branch, same as before.

The big advantage in the proposed approach is the use of the workflow_dispatch trigger (https://docs.github.com/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call) that allow users to manually trigger individual workflows on a given branch directly from the GitHub UI (Go to the Actions tab, select a workflow on the left column then click on the "Run workflow" button on the right - you can try on my fork).

The main drawback of this approach is that it is quite harder to prevent forks to trigger the workflows when pushes happen in the dev branch (the workflow is currently skipped with a condition in each job).
I guess if TTK developers don't want to have CI workflows automatically triggered, they have to work with branches (or temporarily disable the triggers in the workflow file in their own dev branch).

This PR makes also a few updates in the workflows:

• workflow environment variables are used to drive CMake (generator, build type, sccache, etc.)
• mozilla-actions/sccache-action replaces f3d-app/sccache-setup-action. I never saw any cache hit in the "Show sccache results" steps. With mozilla's action, this seems to works better. The cache summary is now displayed on the "Summary" view of the workflow
• the check_code workflow has also been integrated in the test_build workflow through workflow_call and can also be manually triggered with workflow_dispatch. I removed the tag push and the pull request triggers (everything is handled in test.yml).
• warnings during CMake configuration have been silenced by setting CMake policies in the workflow files
• several pvsm were taking a very long time to run on Ubuntu or macOS, they have been skipped.

Enjoy,
Pierre

[julien-tierny]

shouldn't we silence these warnings by default? (i.e., in TTK's CMake files)

[pierre-guillou]

We should. I've tried a bit, it might not be that simple.
Maybe in a future PR, if I find a better solution.

[pierre-guillou]

Done

[julien-tierny]

Thanks a lot @pierre-guillou !!!

[julien-tierny]

Looks great, thanks!