In the first place, multithreaded code is difficult to write and to debug. Most programmers can't do either, and the ones that can are hard to find and spend a lot of time to write a small amount of code. The result is that there's not a lot of enthusiasm for this.
The flip side is that the cores are becoming more numerous, not faster, so if people want to improve performce, they've got to dive in.
For the most part, the idea seems to be to push the multithreading onto someone else's software. Web servers try to be "stateless". That is, they save no data. Each call to the servers functions (methods) is handled on its own. Actual information is handled by databases and system classes with proven track records. In this way programmers that no one would trust near a volatile field can work hard on applications that, in fact, keep all the cores on a big machine going full tilt.
The other trick is to use parallel programming. Threads that don't share data can safely run at the same time, and most systems provide safe ways to run them without the programmer having to deal directly with locks, semaphores, etc.
On the other hand, it's easy to end up multithreading without intending to or without knowing what multithreading is. (People who do know what it is know to avoid it.) I have the uncomfortable feeling a lot of software is going to start to get a bit quirky--it works right most of the time, but every now and then it does something odd, and no one can reproduce it or track down the cause.
To attempt to answer your questions explicitly:
Tools? I've had good luck with Java, and C# ought to be as good. I don't know know about anything else. I expect the situation to improve a lot. My Netbeans (don't know about Eclipse) IDE generally tells me a lot more than I want to know about my code these days, but it won't--yet--tell me I've got a non-final non-volatile field used outside a synch block.
Who's doing projects in this area? Database developers. OS developers. Other people building tools for the rest of us. I'd expect game developers to be big on this, but they don't seem to be.
What should you learn to better prepare? I'd try writing a program with lots of threads that talk to each other a lot. Theory's important, but you need to do it as well. Also, while the theory (which I didn't get until after I tried to use it and made a big mess) helps a lot with avoiding bugs, it takes pure smarts to figure out how to keep your code from all hanging up waiting for a lock. Coding like this will give you a useful feel for multithreading, even if you never code--or want to code--like this again. Even if you stick with parallel programming and "stateless" code forever more. At least you'll know a MT bug when you see it.
Is this going to be common? Not until there's been a big improvement in languages and compilers. People writing core tools for other programmers (like databases) will do more and more. Multithreading's going to infiltrate a lot of code when no one's looking, and figuring out that this has happened and fixing the code is going to be a big business for anyone who can do it--and wants to. (This actually might become common.)
To be honest I don't know what's going to happen. Multithreaded programming has to take over, and soon. Who want's to sit around while their game/spread sheet/IDE/search engine takes forever to do a job while using 6.75% of the CPU? But how many people would you trust to produce a reliable multithreaded program? I suspect we'll have a handleful of MT programmers doing the MT work and everyone else staying reasonably singlethreaded.