This adds a new main command-line entry point for hdrgen, in the
new main.py.  This new interface is used for generating a header.
The old ways of invoking yaml_to_classes.py for other purposes
are left there for now, but `--e` is renamed to `--entry-point`
for consistency with the new CLI.

The YAML schema is expanded with the `header_template` key where
the corresponding `.h.def` file's path is given relative to where
the YAML file is found.  The build integration no longer gives
the `.h.def` path on the command line.  Instead, the script now
emits a depfile that's used by the cmake rules to track that.
The output file is always explicit in the script command line
rather than sometimes being derived from a directory path.

C89 doesn't have the `restrict` keyword.  When in `-std=c89`
mode, GNU-compatible compilers require the `__restrict` spelling.

When in modes like C99, the _Noreturn keyword is not available in
C.  But GNU-compatible compilers have a `noreturn` attribute with
the same effect on function declarations.

The .yaml files should live next to the corresponding .h.def
files in libc/include/, rather than next to the implementation of
the tool in libc/utils/hdrgen/.  As with the .h.def files, there
is no need for a yaml/ subdirectory under include/.  This simpler
layout is more natural for maintenance and also simplifies build
integration outside the LLVM CMake build.

Summary:
This was originally a hacked together function that served to just
implement some features for OpenMP. That has been moved into OpenMP
itself now that we have exported RPC properly. This can now be deleted.

Consistent with glibc headers, where `noexcept` is used in C++
(or `throw()` in older C++ which llvm-libc doesn't support) in
the public function declarations, `__attribute__((__nothrow__))` is
used in C for compilers that support it.

so that docgen can find our definitions.

Also eliminate the enums. POSIX is careful to call these "symbolic constants"
rather than specifically whether they are preprocessor macro defines or not.
Enums are useful to expressing mutual exclusion when the enum values are in
distinct enums which can improve type safety. Our enum values weren't using
that pattern though; they were all in one big anonymous enum.

Link:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/pthread.h.html
Fixes: #88997

Fix buildbot errors in #118671