by forward-declaring the std::function overload in `stack`, it is able to find the right function to use.
All tests are passing
the ninja file has been tweaked to make it easier to invoke a g++ build on windows
tests added to confirm userdata can be passed into C++ function types
demangle is now named lua_demangle, and the core demangle without any replacements (to fit lua) is just named demangle
Formattings fixes everywhere
Refactoring on function_types.hpp performed to slim down some of the calls: could use more refactoring
Drastically simplified userdata's binding capabilities: constructor supports both `:` and `.` syntax (but member functions DO NOT).
All tests are passing
It's going to take serious work to make it happen in GCC, plus the fact that 4.9 is still giving me
so many errors I can't even read it...
I'll let Rapptz figure it out, but later.
Sexy class bindings, yes!
This should enable operator[] to work in all cases that it is to be expected, thanks to a lot of explicit conversions and some basic overload resolution ranking tricks (e.g., making some conversions a template).
We also need to remember that GCC expects `. template (function name)` in generic code, as it can parse things in a really dumb and silly manner.
But! I left it on the `sol::function` type, because it's necessary to discard returns. The .call is still there, though, just incase you need it. <3
reverse_indices_builder is also there, to make sure we can push and pop without the lua api taking our types and breaking them for the std::tuple returns.
All is at it should be~
