LIBADD to replace DPADD LDADD in most case

[bapt]

Summary

One only have to define LIBADD and the framework will automatically add what is
what is needed as a dependencies when needed so the end user does not have to
track what the libraries it depends on also depends on and everything is
centralized into on place.

This also make the USE_PRIVATELIB or INTERNALLIB magic all automated so the end
the programs does not have to know if they do rely on a privatelib or not.

Fix overlinking on most of cases by only making program depending on what they
really depends on.

Allow each program that uses LIBADD to be linked safely as static.

After this is in it will grow with addition of more libraries and the programs
will slowly switch to use it.

[bapt]

Only src.libnames.mk belongs to this review

[brooks]

I like the LIBADD concept, but I'm not convinced by having to add the DPADD_<foo> and LDADD_<foo> variables in the trivial lib<foo> cases. It's easy to add appropriate :U modified to the expansion to do the right thing automatically.

[bapt]

Yes in most case that can be automatic done

[imp]

I like it and think it's sorely needed. I do agree with Brooks' suggestion though.

[bapt]

Implement @brooks idea which leads so something interesting:
death of the ugly LD${LIBNAME} I introduced before for PRIVATELIBS

[imp]

only problem with this patch is the generic lower-case names used w/o a prefix.

[bapt]

Use _DP_ prefix instead of lowercase _depend suffix

[imp]

My nit-picky nature can't find anything else to complain about.

[bapt]

Closed by commit rS274984 (authored by @bapt).