Keep radix for integer literals in generated bindings

[miikkas]

The radices of integer literals in the input C/C++ code are retained in the generated bindings.

• The radix of a C/C++ integer literal in constant, enum, or macro definition is parsed. If it can't be determined, the code falls back to not doing anything about the radix.
• During Rust code generation, the radix of an integer literal – if it exists – is then used to output the value in that number base.
• New testing is added in the form of unit tests for parsing the radix of a clang token and as a new test header file with its matching expected Rust binding output.
• Existing tests are updated, since several had hexadecimal or octal values that now have the radix kept.

Fixes #3236.

[miikkas]

I have now included additional testing to the PR.

Regarding the 13 failing existing tests: It seems that the differences are due to bindgen now generating, as intended, Rust literals using hexadecimal representation, while the values themselves have correctly stayed the same. Should I fix the expected code accordingly?

[miikkas]

The test I added was changed to use C++14 instead of C23, as it seems that the latter is not available for clang 9.0, which IIUC is used in the CI.

I have changed the expected side of the previously failing existing tests. Those changes are currently included in a separate commit in case that makes review less cumbersome. I will squash it later as instructed in the contribution guidelines.

[miikkas]

I have made the solution a lot more robust and included further unit testing.

r? @emilio

[rustbot]

Error: The feature assign is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.