Multithreaded binary image writes

Changes to address #98 . This is by far the simplest, cleanest and most performance-preserving changeset I could come up with to allow thread-safe writes to a bitwise array. I've included a test command `test_binary_writes.cpp` to verify that the changes work as advertised - compare the output of this command against the same compiled with an unmodified `lib/get_set.h` header. As expected, the problem is worst when the contiguous axis of the mask is the second axis being looped over (see discussion on #98). 

This approach simply use hardware atomic operations to prevent race conditions when writing bitwise data. These are supported on all modern CPUs and part of the C++11 standard. The downside (or upside, depending on your point of view) is that this means MRtrix would now require a C++11-compliant compiler. But then, it also means we could finally start using C++11 features...

**I'd be grateful if everyone could give this a try - I need this tested on as many platforms a possible**, given how big a change this is. Note that you'll need to re-run `./configure` first to set the compiler flags for C++11.

The more serious drawback to this particular approach is that this relies on the implementation of the `std::atomic<ValueType>` class being a thin wrapper around its ValueType - in other words, the only member variable is a single ValueType. There is always the possibility of differences in implementation between different perfectly compliant C++ compilers, and/or on different CPUs. My gut feeling however is that this is likely to be a broadly valid assumption - it certainly is using a recent version of GCC on Intel. I'd expect it to be true on any Intel-compatible CPU/compiler, which covers the overwhelming majority of potential user installations. That said, I've had a few issues with Murphy's Law recently (this being one of them), and I wouldn't be surprised if this fails more often than I'd like...

By the way, any other approach that I could think of to deal with this (aside from preventing the use of bitwise data altogether) would involve very extensive and interdependent changes at multiple levels (Image::Buffers, Image::Handlers and File::MMap, amongst others), and/or rely on various assumptions either on the part of the developer or of the user. I really think we need to avoid that kind of mess if at all possible.