Fix compilation with clang, Xcode 5.1.1 on OS X 10.9.4

(`Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)`)

Instead of accessing shared_ptr and related types through std::tr1::, I put them in the TrenchBroom namespace instead (inspired by http://stackoverflow.com/a/6323298 ), though maybe there should be a different namespace for these.

Most of this is just a find/replace of std::tr1:: to TrenchBroom::, except:

- SmartColorEditor: was getting `error: no viable overloaded '='` for the lines like `return ColorPtr(new ByteColor(0, 0, 0));`.  I don't really understand this, but this is a reduced test case that fails to compile with clang:

        #include <memory>
        class Thing: public std::enable_shared_from_this<Thing> {};
        int main() {
          std::shared_ptr<const Thing> foo(new Thing);
          return 0;
        }

    Something about inheriting from enable_shared_from_this conflicts with creating an instance of a class like `std::shared_ptr<const Thing> foo(new Thing);`.  To fix it I removed the `const` in the shared_ptr type.

- clang rejects comparisons between a shared_ptr and NULL like `if (someSharedPtr == NULL)`. I changed these to look like: `someSharedPtr.get() == NULL`, though from what I read you could also do `if (someSharedPtr)` because shared_ptr implements conversion to bool.

Also, the libfreeimage.a included with trenchbroom wouldn't link for me, so I installed it via homebrew and commented out the `IF(APPLE)` part in cmake/FreeImage.cmake, so my homebrew copy was picked up. This isn't included in this commit though.

Finally, there were more tr1 related errors in gtest that I didn't investigate, but I did get a TrenchBroom.app that starts up.