Revised geometry, child / parent APIs; ditto object boxing

I believe this was the last blocker for experimental.

First things first, I removed experimental's CoronaGeometryCopyData() and CoronaGeometryGetMappingFromRenderData() from the CoronaGraphics API. In their place is CoronaGeometrySetComponentWriter(), which takes a writer callback. The writer is run at a slightly different time (while batching vertices) but is able to achieve the same thing as those two APIs. There is now always a writer in effect: the default simply copies vertex data from incoming display objects into the output stream, i.e. the current behavior. Writers only produce the outgoing data, so have no effect on batching itself.

These are assigned through the Shader::Draw() methods, which now accept zero or more writers. (Writers are run in sequence on the outgoing vertex stream data.)

In addition to streamlining the two geometry APIs, which were already a bit too general for their narrow use case (see CoronaGraphics.h for docs), the writers arose from a couple earlier observations:

When doing the emitter mapping PR, I saw that particles, which can be quite numerous, mostly repeat themselves and only need part of their vertex data. This can burn a lot of RAM at scale. The groundwork should now be there to whittle this down.
Text objects are doing a lot reallocation to deal with offsets, but a writer could stitch that in as vertices are merged. I did in fact use this as a test case (those changes are... somewhere; could scrounge them up on request).

Some other possiblities:

Meshes also have a custom Translate() method, I believe, that might be amenable to this.
Vertex compression, if support is available, might also be worthwhile.
Rebasing image sheet frames to [0, 1] for effects, or to allow atlasing of images.

(These being ways to use these features in Solar proper, rather than API-using plugins with out-of-the-ordinary shader needs, say.)

Many APIs in experimental use an handle (an "object box") to native Solar objects. What I had been doing was keeping a list of the boxes, but the "get child" and "get parent" routines have no deterministic limit: a display object might have a great-great-great...-grandparent, for instance, or a group could have hundreds of children. The list could consume a lot of memory, on the one hand, as well as be difficult to search and validate.

There is now something like a call stack, and a CoronaObjectGetAvailableSlot() API that will reserve a spot in the current scope (there is a limit here, but it's more than 2, which is enough to make placeholders for a parent and child, respectively). The slot is represented by an "Any" object: CoronaObjectGetParent() and CoronaGroupObjectGetChild() both now expect one of these and temporarily box the appropriate object into it, after which it may be used like any other. Subsequent calls will evict the current object from the box, but this also avoids the need for an unbounded list.

The handles are a hashed representation of their position in the scope, with a flag for the "get available" ones as well. The hashing makes it easy to invalidate objects when they go out of scope and also avoids accidental use, say versus the handles just being integer indices.

wyhash was used to perform the hashing. Although I'd been considering just going with one or the other, this seemed distinct enough from the FNV-1a-based GetHash32() and GetHash64() methods I'd also recently added for Rtt_String, so they're both present now. (Neither should have much of a footprint.)

Some of the data structures and macros in CoronaObjects were tidied up to account for all this.

Handle types are now declared via macro (CORONA_DECLARE_PUBLIC_TYPE()), and "Any" included among them.

The API files on Windows (Main.cpp) and Apple (ApplePlatform.mm) have been updated to reflect the above changes.

ObjectBoxList.h was removed and the replacement functionality is in the ObjectHandle.* files and wyhash.h, platform projects being updated accordingly. Looks like I forgot a file or two in the Linux projects before, too. :)

Somebody in earlier testing had pointed out that he was getting errors when reading _properties on display objects. This was from format extension lists, and I had just been instantiating them on demand to account for it. This is pretty wasteful, since no code in the wild is yet using these, so the corresponding properties now return nil when a list has not been registered, and _properties seems to be happy.

coronalabs / corona

Revised geometry, child / parent APIs; ditto object boxing #658