We are finalizing the header inclusion policy, and for our public
headers in the `libc/include` folder, they must use relative path in
`"..."` when including each other.

This PR does the cleanup making sure that all the public header
inclusions in `libc/include` folder use relative paths.

---------

Co-authored-by: Nick Desaulniers <nickdesaulniers@users.noreply.github.com>

Performed en-masse via:

    $ grep -rn "#include <ll" libc/include -l | \
      xargs perl -pi -e 's/#include <ll(.*)>/#include "ll$1"/'
    $ grep -rn "#include <__" libc/include -l | \
      xargs perl -pi -e 's/#include <__(.*)>/#include "__$1"/'

Link: #83463
Link: #83210

Towards the goal of getting `ninja libc-lint` back to green, fix the numerous
instances of:

    warning: header guard does not follow preferred style [llvm-header-guard]

This is because many of our header guards start with `__LLVM` rather than
`LLVM`.

To filter just these warnings:

    $ ninja -k2000 libc-lint 2>&1 | grep llvm-header-guard

To automatically apply fixits:

    $ find libc/src libc/include libc/test -name \*.h | \
        xargs -n1 -I {} clang-tidy {} -p build/compile_commands.json \
        -checks='-*,llvm-header-guard' --fix --quiet

Some manual cleanup is still necessary as headers that were missing header
guards outright will have them inserted before the license block (we prefer
them after).

This header first appeared in 4.4BSD and is provided by a number of C
libraries including Newlib. Several of our embedded projects use this
header and so to make LLVM libc a drop-in replacement, we need to
provide it as well.

For the initial commit, we only implement singly linked variants (SLIST
and STAILQ). The doubly linked variants (LIST, TAILQ and CIRCLEQ) can be
implemented in the future as needed.