[clib] mv to builtins folder since it's hard-coded external

[ferdymercury]

This Pull request:

Changes or fixes:

This is all C code that was copy-pasted from external packages in 1990x and 200x. It was then slightly adapted for ROOT but most of the structure is the same.

This follows the same strategy than #22993

Here, the code is put into the builtins directory. This is done for several reasons:

• consistency with libafterimage, mathtext, glad: they have been all forked from upstream and fixed / adapted for ROOT. Likewise for core/clib, put them in builtins directory to have a better overview of all "dependencies" or borrowed things with upstream counterparts.
• makes it clearer to deal with licensing and copyright notices by better separating source of the code
• builtins folder gives kind of more recognition/overview to original authors (before adaptions and modifications)
• system packagers (eg Debian) might complain less by better clarifying externals vs internals
• when a bug is found in those builtins, it easens the opportunity to crosscheck with upstream whether it was fixed there
• it allows in the future a more easy drop-in replacement with a more up-to-date library rather than a hard-coded copy paste
• Less annoying surface for clang-tidy etc, things from builtins can be filtered out.

[dpiparo]

Thanks for this PR! Besides its intrinsic value, it allows to discuss another topic in my opinion.
After all this time, does ROOT still need this code?
For example https://github.com/root-project/root/blob/master/core/base/inc/Rtypes.h#L29:

#include "strlcpy.h"    // part of string.h on systems that have it
#include "snprintf.h"   // part of stdio.h on systems that have it

sounds a bit vintage. The commit messages also seem to hint to this, e.g. b48975d .

[ferdymercury]

Thanks for this PR! Besides its intrinsic value, it allows to discuss another topic in my opinion. After all this time, does ROOT still need this code? For example https://github.com/root-project/root/blob/master/core/base/inc/Rtypes.h#L29:

#include "strlcpy.h"    // part of string.h on systems that have it
#include "snprintf.h"   // part of stdio.h on systems that have it

sounds a bit vintage. The commit messages also seem to hint to this, e.g. b48975d .

That part would be easy to get rid off, indeed. The most challenging one though will be mmalloc functions used heavily by Root. Unless newdelete is redesigned.