Introduce private SolverInterfaceImpl constructor

[BenjaminRodenberg]

Main changes of this PR

Introduces a private constructor. Closes #1260.

Author's checklist

• I added a changelog file with make changelog if there are user-observable changes since the last release.
• I ran make format to ensure everything is formatted correctly.
• I sticked to C++14 features.
• I sticked to CMake version 3.10.
• 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?

[BenjaminRodenberg]

I'm not sure whether this is actually breaking and must go into 3.0.0 or we could also declare it as a simple bugfix and put it into 2.x.x.

[fsimonis]

This is an ideal fit for an std/boost::optional as it allows differentiating between a user-provided nullptr and no user-provided ptr. This requires an upgrade to C++17 for the std:: version #1201.

It allows you to write:

if (communicator.has_value()) {
  PREICE_CHECK(communicator.value() != nullptr,
    "...");
}

There are 2 ways to implement this cleanly:

1. keep the pimple clean

Have 2 constructors with the same interface in both SolverInterface and SolverInterfaceImpl, then forward the latter two to a single private constructor that takes a ::optional<void *>.

class SolverInterfaceImpl{
public:
  SolverInterfaceImpl(
      std::string        participantName,
      const std::string &configurationFileName,
      int                solverProcessIndex,
      int                solverProcessSize)
: SolverInterfaceImpl(participantName, configurationFileName, solverProcessIndex, solverProcessSize, nullopt) {}

  SolverInterfaceImpl(
      std::string        participantName,
      const std::string &configurationFileName,
      int                solverProcessIndex,
      int                solverProcessSize,
      void *             communicator)
: SolverInterfaceImpl(participantName, configurationFileName, solverProcessIndex, solverProcessSize, make_optional(communicator)) {}
private:
  SolverInterfaceImpl(
      std::string        participantName,
      const std::string &configurationFileName,
      int                solverProcessIndex,
      int                solverProcessSize,
      std::optional<void *> communicator)
}

2. keep the interface clean

Have 1 constructor in SolverInterfaceImpl that takes a ::optional<void *>, then call it from the 2 constructors in SolverInterface.

class SolverInterfaceImpl{
public:
  SolverInterfaceImpl(
      std::string        participantName,
      const std::string &configurationFileName,
      int                solverProcessIndex,
      int                solverProcessSize,
      std::optional<void *> communicator)
}

[BenjaminRodenberg]

This is an ideal fit for an std/boost::optional as it allows differentiating between a user-provided nullptr and no user-provided ptr. This requires an upgrade to C++17 for the std:: version #1201.

As long as we did not conclude on #1201 I'm a bit hesitant implementing it here, because this would make this PR unmergable until we upgrade to C++ 17. The solution sounds reasonable, but does (at the current state) not fit into preCICE (we can still keep it as an issue and improve it in the future).

[fsimonis]

An optional is really only a slight refactoring of this solution. So, let's merge this once CI passes.

[BenjaminRodenberg]

I just realized that this change is considered breaking. Therefore, we should not merge this PR before we are sure that our next release will be v3.0.0. We can still keep this PR open and consider it ready to merge.

[fsimonis]

The case, which could be regarded as a breaking change, would already break MPI.
So, we don't see this as breaking.

[BenjaminRodenberg]

This PR is ready to merge as soon as the tests are complete.