I think the Unix philosophy militates against these kinds of tightly integrated toolchains. It's no accident that Eclipse, the first thing you mention, came from the Java world. Unix (and by extension, Linux) tends to believe less in things called "plugins" and more in sets of tools that share data stored in flat text files.
By "project management" I'm not sure if you mean something like Make or something to keep track of your team's progress. If you mean something like Make, the Unix world sorely needs a reusable Make that supports "smart recompilation" and will work with multiple compilers. The closest thing is Glenn Fowler's nmake, but that's not very close.
Regarding integrate toolsets more generally,
The best set of tools I've seen are the Advanced Software Technology tools built at AT&T. There's a most excellent book Practical Reusable Unix Software, free to download, which describes the state of play circa 1995. Since then the toolset has only gotten better and richer, but to get an overview of what the hell is going on, you really need the book. These guys started with the Unix group at Bell Labs, and what they've created is not so much a toolchain but a way of life. Joe Bob says check it out.
The other ubiquitous element in many Unix toolchains is (and this is likely to make you laugh or puke) Emacs. Although Emacs Lisp is not anyone's favorite way to write plugins or extensions, sheer accumulation over time has made Emacs into a very rich, powerful programming environment—and it talks to all sorts of other tools. I'm into simplicity, not complexity, so I try to keep to shallow water, but if you're serious about investigating toolchains for Unix, it's something to know about.
I'm looking forward to seeing more answers to your question.
