Philosopher's stone

Fired the old procedure/callback APIs. They have been re-implemented, using more straightforward styling. Primarily the change is to promote sound coding logic, and allow for the possibility of parsers & transcoders to do minimalist work.

For the time being ellipsis calls have been "disabled". Elliptical arguments present quite the problem for a weakly typed system. We cannot simply "scan" the format string because not every variadic procedure uses a format string!

The solution in regards to ellipsis is any combination of the following:

* Mark each value with "conversion hints"
* Mark variadic types explicit "per-call" with an layered call invoke as such:
   `function(type, type, type)(value, value, value)`
* Only support automatic conversions to bool, char, long, utf8 *, and double

Either way, ellipsis is looking really shitty to me from this vantage point. I want the code to look the way it looks in a C program whilst executing, so either we go automatic, or "type hinting", automatic is the only form fitting function. I think I will settle for automatic, supporting coercions through hinting where confusions are likely to crop up.

Also need to "crack the code" on dyncall's struct & union interface. With these additions, we will have a fully native interface provided we also implement enumerated values and (preferably) C header parsing.