[REQ] [C++] Support for unsigned integers

Is your feature request related to a problem? Please describe.

I didn't find any information about support for unsigned integers in OpenAPI Specification.
I dunno how much of an issue it is for interpreted/JIT languages, but I'd see this as a annoyance for C++ (introducing a lot of unnecessary casts between my code and generated code, which is also an opportunity for a bug (imagine calling to_string and getting negative number written somewhere, because you forgot to cast it to correct type. It won't spit a warning if you use auto.).

Describe the solution you'd like

Simply add type mappings for type: integer and format uint32 or uint64 - in C++ that would be std::uint32_t and std::uint64_t.
That's simple on C++'s side, I'd just add type mappings, but what about the specification which doesn't mention unsigned integers? Also what could happen to other languages which may not have this problem (if we edit specification to add it)?

In Rust server generator I've found something like this

        if ("integer".equals(property.baseType)) {
            // custom integer formats (legacy)
            if ("uint32".equals(property.dataFormat)) {
                property.dataType = "u32";
            } else if ("uint64".equals(property.dataFormat)) {
                property.dataType = "u64";

This would make it undocumented feature of selected generators, is that a valid approach? If yes, then I'll do the same for C++ generator(s).

Describe alternatives you've considered

Casting stuff like madman 😁
Is there a way to stupidly force a type (like writing std::uint64_t as type in YAML file)?

Additional context

Tagging C++ Technical Committee and @wing328 since he's a member of core team.
@ravinikam @stkrwork @etherealjoy @MartinDelille

Start by reviewing the OpenAPI Specification's integer formats and the Rust server generator mapping shown in the issue, then inspect the C++ generator's type-mapping entry point. Determine whether uint32 and uint64 should be documented formats or generator-specific mappings, and validate the chosen behavior with the generator's existing tests.