[libc] [llvm] [libc] Provide an implementation of the 'stdint.h' header (PR #83353)

[Nick Desaulniers via llvm-commits]

nickdesaulniers wrote:

To be clear, I am in favor of this.  I just have a sinking fear of "what could go wrong?" that is perhaps just being overly cautious.  I don't have anything specific in mind as an answer.

> > If we did do this change, I think we could+should replace our `#include <stdint.h>` with including our stdint.h.
> > ```shell
> > $ grep -rn '<stdint' libc | wc -l
> > 208
> > ```
> 
> If we replaced this it would have equivalent behavior to compiling with `clang -ffreestanding`.

`-ffreestanding` is more than just `<stdint.h>`; llvm will elide libcall optimizations.

My point was more so that I think we should match

72ce6294157964042b7ed5576ce2c99257eeea9d

where we had too many issues from using `<limits.h>` and instead now provide our own and use that everywhere.  I think we should do exactly that, but for `<stdint.h>`, for the same reasons.

I'm also trying to fix all of the lint warnings (#65694) where we do warn about including system headers (such as `<stdint.h>`). I'd prefer to try to curtail these kind of inclusions to one place (when necessary) (or omit entirely when we have our own impl) so that we can throw `NOLINT` on the single includes then consistently use our wrappers.

Also, looking at 72ce6294157964042b7ed5576ce2c99257eeea9d, I wonder if this PR should be updating libc/spec/stdc.td in a similar manner?

>> I do worry about #include_next as I highly suspect it's behavior is non-deterministic in the face of -I (or perhaps -isystem) flags.
> This does not use the include_next part, that's handled in clang.

Right, which is why I'm in favor of providing our own.  I was implying that I don't like the alternative.

> Also it would probably pick this up by default because we `-I/libc/install` in the output directory.

What we do with our build flags won't affect what happens when users consume our headers. They won't be adding `-I /libc/install` for instance.

https://github.com/llvm/llvm-project/pull/83353