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)

There won't be any clashing with other libraries imported via CFFI (unless those are imported with the internal cffi instance pyopencl uses). There will be clashing with all other c libraries loaded just like what dynamic linked libraries usually would. In that sense, I don't think having `pyopencl_` prefix is a bad thing (although I would probably use `pyocl_` to save some typing) and the main reason I removed this is,
1. The clashing is not CFFI specific so that explanation is wrong.
2. Most of the functions below does not follow that guild line anyway......

As I said, having a `pyocl_` or `pyopencl_` prefix might be nice (so that other random libraries that uses functions with the same name from another library will not call into pyopencl). And I can add them along with a correct explanation if necessary.