- fix if

So we can debug some without spamming CDash

But any non-trivial logic in a script, we can develop and test it locally.
This is a win-win-win over putting all of this logic in the GitHub Action YAML
file.

This should have the proper site name, build name, use the correct generator,
and enable or disable Fortran correctly.

Why not let the jobs run all at the same time?

We have a real GitHub Actions now.

The script now creates and cds into 'tribits-build' subdir.

…ng, improve output (TriBITSPub#363)

Hopefully this will run correctly now for all of the build from the GitHub
Actions YAML file.

We will need to install docutils if we want to test the generation of
documentation.

…TSPub#363)

Makes easier to read.

I suspect that some of the tests are not robust enough to work with Ninja as
the outer generator.  There are some tests that will use Ninja for the inner
configure to make sure that it works.

Making the entire TriBITS test suite pass using Ninja as the generator in
place of Makefiles would be a lot of work.  Or, we could conditionally enable
many of the tests that depend Unix Makefile logic.

Nice to set just for completeness.  Not really related to TriBITSPub#363 but I did this
while workoing on that.

I also moved -DDART_TESTING_TIMEOUT=60 up in the argument list because
-DCTEST_PARALLEL_LEVEL=16 these kind of go together.

This is one of the test cases being enabled for the GitHub Actions builds for
TriBITS in TriBITSPub#363.  Just reproducing locally and fixing.

…#363)

All of these tests fail to configure because we don't pass down the
ENABLE_Fortran configure option to the inner CMake configure and if a working
Fortran compiler does not even exist on the system, then these tests fail in
the configure of the inner project.  While I could pass down this info
somehow, a lot of these tests would fail anyway without some adjustment.

We don't need every test to run if we don't have a Fortran compiler.  We just
don't want the TriBITS test suite to have a bunch of failing tests if a user
clones the repo and tries to build and run the TriBITS test suite on a machine
with no Fortran compiler (like a Mac or a Windows machine).

…#314, TriBITSPub#363)

With CMake 3.21, with umask=g-rwx,o-rwx you need explicitly set g+rX for the
group permissions to be r-X when setting
<Project>_MAKE_INSTALL_WORLD_READABLE=ON which was doing just:

  chmod -R o+rX <dir>

Now, when you ony set <Project>_MAKE_INSTALL_WORLD_READABLE=ON, you get:

  chmod -R g+rX,o+rX <dir>

For some reason, with older verisons of CMake, it was setting the default
group permission as 'r-x' when it should not have been.  I ran exactly the
same build on the same machine (crf450) with the same env except I used CMake
3.21.0 vs. 3.17.1 and I had to make this change to get the same permissions on
the base install directory.  Strange.

For CMake 3.21 it prints a "could not find requested file" instead of "could
not find load file".  The latter was obviously a typo so it is good they fixed
it but I had this checked for in a test.  Now the test passes in both cases.

…riBITSPub#363)

Seems CMake 3.21 reports two install failures instead of just one as older
versions of CMake reported.  I guess it depends how you count.  Either way,
the number is greater than 0 so that is what matters really.

I searched the git logs and it looks like this change was pulled in the CMake
3.18.0 release.  But I only tested this with CMake 3.17.1 and 3.21.0.

…ging code (TriBITSPub#363)

With CMake 3.21, this was generating a deprecated warning.  With the rest of
TriBITS requiring CMake 3.17 it seems bad to have code that has min version
going back to 2.6.  However, this might change the behaivor of this code so
that is a warning.  (Fingers crossed.)

…ithub-actions-ci (TriBITSPub#363)

Merge in the fixes of the tests that should fix all of the nofortran failures
and three of the cmake-3.21 failures.  But we expect there to still be 10
failing cmake-3.21 failures due to changes in CMake 3.21 behavior vs. CMake
3.17 that appears to be regressions.