As reported some weeks ago ufsdump fails to link on the upcoming Fedora

As reported some weeks ago ufsdump fails to link on the upcoming Fedora
13 release due to linking issues, and as reported by Amos the same
linking issues is now also seen on Debian since somewhere between March
2 - 5.

While investigating this I found the following conclusions

- We are not actually installing ufsdump
- The dependencies between the Squid libraries are very non-obvious,
with libraries depending on plain object files and other strange things.
- The ufsdump linkage issues is somehow triggered by the libraries
including objects needing symbols from objects not included in that link
- Those failing library objects are not actually needed by ufsdump.
Linking succeeds if repeatedly removing each reported failing object
from the squid libraries.
- If the libraries were shared libraries then linking would fail on all
systems

The issue have been identified, or actually two separate issues. What is
yet unclear is what is the proper solution..

- Inline operator overloading causing indeterministic linkage,
resulting in seemingly unneeded sub modules being pulled in "at random".
Most notably this is seen with our custom new operation (which btw is
duplicated in two places: src/SquidNew.cc and include/SquidNew.h)

- The current Squid libraries have very unclear dependencies with no
  clean boundaries, resulting in linking failure when the above happens..