Implemented irr.core

I'm pleased to say that I've completed implementing the irr.core module.

Well, anyway, as much as I'm going to do at this time. Actually, a few types remain unimplemented: array, list, string, irrAllocator, and irrAllocatorFast. The allocator classes have no relevance to Python and as such will never be implemented. The utility types array, list, and string may be implemented eventually in the interest of completeness, but given that Python provides built-in types to do what these types do, I don't view them as important enough to spend time on until after the rest of the binding is working.

This module was a bit of a bear. I've tried hard to faithfully reproduce the signatures of the functions, but there were three major issues that regularly tripped me up.

First was the C++ practice of using non-const reference parameters to return values. This is natural in C/C++, since you can only return a single type from a function and its a drag making structs and whatnot to get around that. Python, on the other hand, more naturally returns different types or tuples in the same sort of situations. For example, some functions returned bool and an output parameter, the bool signaling when there was no meaningful result. In Python we handle the same situation by returning the value if valid and None if not.

The second is C++ overloaded functions. Sadly this forces me to hand-implement the functions. Not a big deal, but it does break one's rhythm.

The second and much more vexing issue was the basic problems in the Irrlicht codebase itself. This was particularly an issue with the various types like vector3d that are templated and come in float and int flavors. Nearly every such type with non-trivial member functions displayed conversion warnings and sometimes outright build errors when instantiated with int types. Some of these problems are unavoidable, such as attempting to normalize most integer vectors, while some are just the result of poor testing. I've complained about this before. These sorts of problems led to a lot of ugly cursing on my part and even uglier workarounds, since I can't fix the issues directly in Irrlicht. But in the end, the int variants got implemented. A related and less common problem was the occasionally flubbed function signature; taking a param by value instead of the obviously more appropriate reference, for example.

I'm sincerely hoping that the int/float related issues will not reoccur throughout the rest of the library. That by far was the most troublesome issue. Reference parameters and overloaded functions are inconveniences, but at least well-solved issues. The build breakage required different custom workarounds unique to every situation, and were a huge time sink.

Up next: the irr.io module.