Singleton

Hey Austin!

In these commits I have essentially created a singleton for a global python to C++ exception translator. Users can create an exception translator using the functionality we already provide. The singleton is not user-visible, but can be accessed using free-standing functions.

With this, I made an effort to wrap boost::python's import() function using functionality from boost_python_exception. I am not entirely happy with how this wrapping turned out, and I have three main issues in import.cpp:
1) The actual wrapping code will be extremely similar for other features. We need a way to get readable code without duplication, and all this without C++11 (which would make it straightforward).
2) There is no return value in the catch block. Assuming that the exception translator always throws is one thing, but the compiler would complain with reasonable warning levels.
3) If I want to translate a python error to a C++ error, it makes sense to clear the python error once it has been translated properly. The problem is that I need to call clear_exception() before doing the actual translation, since the translate() function is expected to throw. If the translation itself would fail for some reason (std::bad_alloc, for instance), the original python exception would be lost.

I guess boost may have convenient macros for 1). Points 2) and 3) probably boils down to a weakness in the design of our established exception_translator::translate() method. The latter actually does two things, since it translates a python exception into a C++ exception and throws it. If we were to separate those steps into a (probably throwing) translate and an additional throw command, we could exploit this to fix 2) and 3).

Anyways, it would be great if you could review the changes and share your thoughts on above issues (which we can address later).

Cheers

Michael
I'm not sure if this design - creating a separate namespace for auto-translating versions of functions - is the best way to express the optional behavior. One problem I can see is that it becomes more difficult to dynamically select the auto-translation behavior, either at compile- or run-time. 

But I don't feel so strongly about it that I think we need to change this patch. Let's just keep it like this and see how it works out.