libroot_build: Properly remap fs_attr_* functions.

This was done using macros before, which isn't the way we have things set up.
In theory that method should work, however if not all consumers include the
libroot_build headers properly, then it breaks in subtle but confusing ways,
which is not what we want at all.

Thanks to Jessica for advice.

Change-Id: Idd45df5547daecf8239932957088da03ddfccf87

Split fs_darwin.h defines into various platform dependent headers.

This completes the final 1/3 of #8857. Changes again by nielx with
style fixes by me.

The one part that I couldn't figure out, and maybe Ingo can chime
in here. If headers/build/host/darwin/sys/stat.h is surrounded in

extern "C" {

}

guards then I get a link error complaining that the functions defined
here are duplicate symbols, once in fs.o and once in function_remapper.o.
For example:

ld: duplicate symbol _futimens in generated/objects/darwin/x86_64/release/build/libroot/libroot_build_function_remapper.a(function_remapper.o) and generated/objects/darwin/x86_64/release/build/libroot/libroot_build.a(fs.o) for architecture x86_64

I'm not sure why that is.

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.

Split fs_darwin.h defines into various platform dependent headers.

This completes the final 1/3 of #8857. Changes again by nielx with
style fixes by me.

The one part that I couldn't figure out, and maybe Ingo can chime
in here. If headers/build/host/darwin/sys/stat.h is surrounded in

extern "C" {

}

guards then I get a link error complaining that the functions defined
here are duplicate symbols, once in fs.o and once in function_remapper.o.
For example:

ld: duplicate symbol _futimens in generated/objects/darwin/x86_64/release/build/libroot/libroot_build_function_remapper.a(function_remapper.o) and generated/objects/darwin/x86_64/release/build/libroot/libroot_build.a(fs.o) for architecture x86_64

I'm not sure why that is.

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.