Ragdoll Part 12: first pass avatar skeleton collides with voxels

The avatar skeleton now collides with voxels when ragdoll mode is enabled.  However, there are some known issues:

(1) Skeleton shapes will collide with internal faces between adjacent voxels, so colliding against a row of small voxels will do strange interpenetrationary things.

(2) The penetration resolution works independently for adjacent capsules in the skeleton, so what tends to happen is the tip of a finger might get pushed up out the top face of a voxel while lower joints are pushed out the front -- the result is somewhat chaotic when the constraints are enforced.  Typically the lower joint is heavier and more constrained (attached to the hand etc) and so the tip of the finger is pulled back to collide with the front of the voxel.  In short: when you drop a hand down on top of a voxel, near an edge, the hand will eventually be pushed out the side (with broken fingers) rather than resting on top.

(3) The avatar's bounding capsule is not used for floor collisions when the ragdoll is colliding against voxels.  Intstead the avatar's feet and legs will collide against the floor.  It is kinda cool that this Just Works, but it causes two problems:

(3a) Gravity is pulling the avatar skeleton down, collisions push the feet out, and constraints lift the rest of the body up.  The result is that there can be partial (and intermitent) collapse of the torso when there aren't enough iterations of the constraints to fully propagate up the chain of joints -- the torso will dip and weave a bit when the avatar just stands there.

(3b) The avatar cannot walk up steps anymore.  There is no special handling of avatar foot collisions so the general penetration resolution between the feet and smaller voxels can be as much to the side as it is up -- the net result is that the legs will tend to be pushed akimbo rather than straight up when colliding against a platform made of small voxels.

Dunno yet if there are easy ways to solve all of these problems, but will think about them tonight.
Yup, this was intentional because in the context of VoxelShapeManager::updateVoxels() I figured: "Why bother recomputing the hash of the center (which itself needs to be computed from AACube::_corner + _scale)... when instread I can just recyle the existing key?"   Hence CubeList and VoxelPool use quint64 as a key.

Hrm... I suppose I should have made that a uint since it gets hashed again underneath.