Add framework for benchmarks

[fsimonis]

Main changes of this PR

This PR adds a framework for implementing benchmarks using the popular benchmark.
As this introduces another unnecessary dependency, the generation of the benchmark suite is disabled by default.

cmake -DPRECICE_ENABLE_BENCHMARKS=ON .. enables the generation of the benchmark executable benchprecice.

Add your benchmark as a .cpp file in the benchmarks/ directory and run tools/building/updateSourceFiles.py.

Motivation and additional information

This is a first step towards performance regression testing.

There are currently no benchmarks.

Author's checklist

• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I added a changelog file with make changelog if there are user-observable changes since the last release.
• I added a test to cover the proposed changes in our test suite.
• For breaking changes: I documented the changes in the appropriate porting guide.
• I sticked to C++17 features.
• I sticked to CMake version 3.16.3.
• I squashed / am about to squash all commits that should be seen as one.

Reviewers' checklist

• Does the changelog entry make sense? Is it formatted correctly?
• Do you understand the code changes?

[fsimonis]

Open question: should we build these in the CI pipeline as well?

[davidscn]

For now, I only benchmarked 'non-coupled' scenarios. I'm not sure if we can benchmark coupled API functions at all.

[davidscn]

In accordance to other executables around preCICE, I would call this precice-bench. I would even consider merging it optionally with the precice-tools

[fsimonis]

Good point. Renaming testprecice would also make sense.

[davidscn]

Open question: should we build these in the CI pipeline as well?

Experience states that it will become outdated otherwise.

[fsimonis]

For now, I only benchmarked 'non-coupled' scenarios. I'm not sure if we can benchmark coupled API functions at all.

Right. We will be able to benchmark internals, such as Mappings, Meshes, Exporters as well as everything SolverInterface-related until the call to initialize.

Experience states that it will become outdated otherwise.

Sure. This simply means that we have to add this dependency to all ci images.