Bump CBMC_VERSION to 5.12.6

[hannes-steffenhagen-diffblue]

We use this version number to make debugging easier, it should stay up to date with the current release version. Updating it automatically is WIP.

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[peterschrammel]

Shouldn't the git tag be the single source of truth?

[hannes-steffenhagen-diffblue]

@peterschrammel We currently use both this and the git tag. We could alternatively change how we do versioning to only take the git tag into consideration; The only problem is then what version do we put on code built e.g. from a source tarball (though I suppose that could be fixed by making sure version.cpp is included with that?).

[thomasspriggs]

I think we need to keep the version number in src/config.inc, as long as we want the ability to build cbmc from a downloaded tar ball. Automatically fetching the version number from git as the single source of truth would mean that we can only build from a git checkout.

[thomasspriggs]

Approving as this makes config.inc consistent with the current state of the git tags.

[peterschrammel]

Yes, given that we distribute source tarballs, the version number must be somewhere inside.