Fix GTest linking

[tpadioleau]

From https://cmake.org/cmake/help/latest/module/FindGTest.html#imported-targets:

Only link to GTest::gtest_main if GoogleTest should supply the main() function for the executable. If the project is supplying its own main() implementation, link only to GTest::gtest.

We already provide the main function in the file gmgpolar_tests.cpp.

Merge Request - GuideLine Checklist

Guideline to check code before resolve WIP and approval, respectively.
As many checkboxes as possible should be ticked.

Checks by code author:

Always to be checked:

• There is at least one issue associated with the pull request.
• New code adheres with the coding guidelines
• No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

If functions were changed or functionality was added:

• Tests for new functionality has been added
• A local test was succesful

If new functionality was added:

• There is appropriate documentation of your work. (use doxygen style comments)

If new third party software is used:

• Did you pay attention to its license? Please remember to add it to the wiki after successful merging.

If new mathematical methods or epidemiological terms are used:

• Are new methods referenced? Did you provide further documentation?

Checks by code reviewer(s):

• Is the code clean of development artifacts e.g., unnecessary comments, prints, ...
• The ticket goals for each associated issue are reached or problems are clearly addressed (i.e., a new issue was introduced).
• There are appropriate unit tests and they pass.
• The git history is clean and linearized for the merge request. All reviewers should squash commits and write a simple and meaningful commit message.
• Coverage report for new code is acceptable.
• No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

[tpadioleau]

I am also noticing that we build twice the tests:

• Serial
• Parallel with 16 threads

I find it very unfortunate because:

• CPU parallelism may not be available in Kokkos if for example it is only built with Serial backend,
• the number of threads to use is a runtime parameter.

I would suggest to only compile once and run twice ctest in the CI with different values of OMP_NUM_THREADS. If you agree with this I can open PR.

[julianlitz]

You can also just get rid of either the serial or the parallel version of the same test.
I only used them to find potential race conditions in the "A-Give" approach.

[tpadioleau]

You can also just get rid of either the serial or the parallel version of the same test. I only used them to find potential race conditions in the "A-Give" approach.

Then let's keep a single build, it will be serial or parallel depending on how Kokkos is compiled. @EmilyBourne ok for you too ?

[EmilyBourne]

You can also just get rid of either the serial or the parallel version of the same test. I only used them to find potential race conditions in the "A-Give" approach.

Then let's keep a single build, it will be serial or parallel depending on how Kokkos is compiled. @EmilyBourne ok for you too ?

I did it this way because the old version had lots of tests that were identical apart from the number of threads (with 1 or 16). I just tried to reproduce the existing tests. I am ok to only have 1 build as long as it doesn't cause problems for testing/debugging