WIP: Mount tooling in C

[flo91]

Basics

This PR has basically the same content as the PR #4851, but it should be merged into kdb_cli_rewrite instead of mount_cli_integration.

I created a new branch based on the current version of the kdb_cli_rewrite branch.
The upstream branch mount_cli_integration contains the commits of kdb_cli_rewrite and on top of that the commits for the mount-tooling, which are also included in this PR.
The problem is, that the commits in mount_cli_integration that originally came from kdb_cli_rewrite have a different SHA1 than the commits in kdb_cli_rewrite.

This PR contains the original commits from kdb_cli_rewrite with the correct SHA1-hashes.

tl;dr: The branch mount_cli_integration on upstream can be deleted.
Then we have only kdb_cli_rewrite on upstream and my PRs are based on that branch and target it.

• Short descriptions of your changes are in the release notes
  (added as entry in doc/news/_preparation_next_release.md which contains _(my name)_)
  Please always add them to the release notes.
• Details of what you changed are in commit messages
  (first line should have module: short statement syntax)
• References to issues, e.g. close #X, are in the commit messages.
• The buildservers are happy. If not, fix in this order:
  • add a line in doc/news/_preparation_next_release.md
  • reformat the code with scripts/dev/reformat-all
  • make all unit tests pass
  • fix all memleaks
  • fix the CI itself (or rebase if already fixed)
• The PR is rebased with current master.

Checklist

• I added unit tests for my code
• I fully described what my PR does in the documentation
  (not in the PR description)
• I fixed all affected documentation (see Documentation Guidelines)
• I fixed all affected decisions (see Decision Process)
• I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
• I updated all meta data (e.g. README.md of plugins and METADATA.ini)
• I mentioned every code not directly written by me in reuse syntax

Review

• Documentation is introductory, concise, good to read and describes everything what the PR does
• Examples are well chosen and understandable
• Code is conforming to our Coding Guidelines
• APIs are conforming to our Design Guidelines
• Code is consistent to our Design Decisions

Labels

• Add the "work in progress" label if you do not want the PR to be reviewed yet.
• Add the "ready to merge" label if everything is done and no further pushes are planned by you.