Cffi c++0x

So I've finally decided to submit this pull request which introduce c++0x in the cffi branch after using it for a few months. In addition to using c++0x, this patch set also removes some C macros and replaced them with templates. The advantage of doing this includes,

1. Typesafe and unified wrapper of OpenCL calls. `pyopencl_call_guarded` can be used to call OpenCL functions that returns the status either in returned value and in the pointer passed by the last argument (some OpenCL 2.0 functions seem to break this convension but the corresponding wrapper can easily be added)
2. Removing macros that must be used in conjunction with a counterpart
3. Runtime type check with virtual methods
4. Being able to use c++11 std lib when the python std libs are not available.

There are of course several drawbacks,

1. Using c++ features in the cffi branch increases the compile time significantly (However, it is still much faster than the master branch which uses boost)
2. Requiring c++0x drops support for old compilers. However, both gcc and clang had support for all the features I need for more than one year. Assuming that the cffi branch is mainly used to run pyopencl on pypy (the master branch should be faster on cpython) and given that pypy 2.3 released mid this year (and even 2.4 released a few days ago) is still missing important bits in numpy to run pyopencl, the requirement on the compiler shouldn't be a big problem. Also, compiling an up-to-date enough compiler should be much easier and faster than compiling an up-to-date pypy. (For the very reason I will not necessarily suggest using c++0x in the master branch although it might be a good thing to consider when the standard is implemented in more compilers and when major distros have upgraded to the new versions.)

In additional to the major changes mentioned above, this patch set also includes,

1. Implements a LOOOOT of missing functions, the test has a 100% pass rate on cpython2 now. There's still missing functions and bits to improve (details in TODO, one of the major missing function is GL interop) but most of the functions are implemented.
2. The non-cffi specific part is almost identical to the master branch. (with a lot of them the name difference between the backend (cffi_cl vs _cl ....)) It might even be possible to merge the two branch and select the backend at compile/runtime (like what pyzmq is doing)
3. Consistent naming of the c interface
4. Split c source files
5. Automatic type conversion and logging with argument for CL-API call. The logging can be controlled by environment variable and can be toggled at runtime with c/cffi function for debuging. When the logging is off, the only runtime overhead is checking a bool value.
6. `Event.set_callback`
7. .... Added myself to the `__copyright__` in the cffi source file....
8. Add new types defined in OpenCL 2.0 (although no functions implemented yet.)

The whole thing is tested with libOpenCL 1.1, 1.2 and 2.0. On CPython2 and PyPy.
As I mentioned, it has 100% pass rate on CPython2 (although the test is not very complete) and there are < 10 failing tests on PyPy some of which should be fixed by my recent [pypy pull request](https://bitbucket.org/pypy/pypy/pull-request/283/implement-numpygenericitem-do-not-let)

Does it?
See [this](http://nbviewer.ipython.org/gist/yuyichao/b054dc909f4712d11761).

Note that each `FFI` instance has only one namespace, but both the library and the ffi instance are pyopencl private object and they do not conflict with other cffi user unless they somehow prefer using the pyopencl instance....