Use the SymEngine's C API instead of the C++ API

[certik]

This has the following advantages:

1. Cython only needs to be run in the C mode, so it will be much faster to compile (i.e. gcc instead of g++), and we avoid the Cython bug #66.
2. The C wrappers will be much better tested and complete, since if we want to expose something to Python, we would have to wrap it in C, and thus Ruby/Julia and other languages can easily take advantage of this as well (and vice versa).
3. I think the Cython code will simplify quite a bit (no template tricks, etc.)

Possible disadvantage:

1. The result might possibly be slower than calling C++ directly in some cases. If that happens, we should think hard if there is a way to create a C wrapper with minimal overhead (I think we are already pretty good about this). I still think that the only overhead is a possible extra function call in the C wrappers --- but if an extra function call makes a difference in Python wrappers, then the code should not be in the wrappers or in Python, but rather it should be moved to symengine itself into C++.

[certik]

Here is another bug that would not happen if we switched to C: #106

[ShikharJ]

@certik @isuruf Is this still relevant? SymEngine's C API isn't near completion, and as such we'd only be able to port over the changes for a small number of functions. Moreover, the mentioned bugs seem to have been fixed, and I have my reservations about the performance impact.