Link with LINK.c

Define link with LINK.c similar to LINK.cc
(i.e. use START_OBJ, STDLIBS, END_OBJ)
More binutils

More utils from binutils (with cross-compilation
instrumentation): nm, objdump, objcopy, readelf.
Explicit dependency for *.o files

Re-write compilation rules generator.
Rules now use explicit (instead of former implicit) dependency
for .o files from source. It generate rules like

obj/gcc/so/test.o:	test.cc | obj/gcc/so
 	$(COMPILE.cc) $(OUTPUT_OPTION) $<

For source not from current dir (i.e. src/test.cc) generated rule will
be like

obj/gcc/so/ebc28af801846844e4024f299405a1c4/test.o:	src/test.cc | obj/gcc/so/ebc28af801846844e4024f299405a1c4
 	$(COMPILE.cc) $(OUTPUT_OPTION) $<

Generator add appropriate .o file to OBJ (or OBJ_DBG, ...),
.d to DEP (DEP_DBG, ...), output catalog to OUTPUT_DIRS

The hash string is MD5 hash from string "src/" (i.e. directory part of
source, with tail slash). This allow to resolve target ambiguities
without creation of catalogs tree for output files similar to source tree.

The usage is like:

$(call derive_rule,$(OUTPUT_DIR),test.cc,.o,$$(COMPILE.cc) $$(OUTPUT_OPTION) $$<)

This allow to compile/link/archive units with same object (.o) names
from different catalogs. But usage of different sources for same .o
name in the same catalog (for example, src/test.cc and src/test.c) still
_not supported_.

The set for PRI (primary) program/libs is really the same as for specific
(PRGNAMES, LIBNAMES). Nevetheless I keep both because of messy syntax
(escape dollars) and complicated rules debug for specific targets.
Fix dependencies for .pdf from .tex

More accurate calculation of dependencies
for LaTeX/biber (take into account bibliography).
Fix tags/TAGS generation