Add exceptions to precice errors

[fsimonis]

Main changes of this PR

This PR

• adds an exception hierarchy.
• extends PRECICE_ERROR(precice::APIError, "Oh no!") to take an exception type first.
• migrates all error calls to exceptions
• catches exceptions and aborts in the C and Fortran bindings

Motivation and additional information

This allows us to test failing cases.

Closes #280
Closes #1189

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?

[davidscn]

Looks good and will make out live easier in the future.

Only a few comments:

• although it is somewhat of an open question on how we treat the exceptions in C and Fortran, we duplicate quite a lot of code due to the usage of try{} catch (...) {}
• our test coverage will now complain if we don't test the throw's in our CI
• we need to export the exceptions header to the (user) installation include target

I would propose to keep the number of exceptions in preCICE rather small (maybe the four most significant) and extend later on demand. We could summarize smaller groups in precice::InternalError or something similar. Let's discuss in person.

[davidscn]

Can this function throw at all?

[BenjaminRodenberg]

I agree with the suggestion of @davidscn to keep the number of errors small for the beginning and find out what we need later. The main motivation here is to simplify using the correct error in the correct situation. Two concrete ideas:

• Only use a single exception for now: Error. We can extend this later? Then there is no risk of wrong or inconsistent usage of error classes, because everything is simple.
• The errors below are basically one error class per package. From my perspective this means that there is implicitly the rule: "Use ActionError, if you want to throw an error from precice::action". This rule is simple enough to not mess up things from the beginning, but we should also put this into the documentation of each error class.

[BenjaminRodenberg]

Related to my comment above. I think we should put this error into the namespace precice::action. This makes it clear that the error should only be thrown from this package.

[fsimonis]

We decided to:

• drop MeshError
• drop M2NError (unused)
• rename IOError to ExportError
• Use ExportError for the WatchPoint and WatchIntegral. Move them from precice/impl -> io
• eventually rename the io package to export

Users should only be interested in catching a precice::Error.
We need other more refined errors in the tests.