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.
I'm going to go ahead and merge this as is... since it functionally achieves your goals, and is similar to what we discussed, but actually, there's a cleaner "more Qt" way of doing this... The "qt" way to do this would be to do something like this...

**Define operator==() and qHash() functions for your key type**
```
// NOTE: this probably already exists, so you don't need this.
inline bool operator==(const glm::vec3& a, const glm::vec3& b) {
    return a == b;
}

inline uint qHash(const EntityItemID& a, uint seed) {
    quint64 temp;
    // NOTE: TREE_SCALE = 16384 (15 bits) and multiplier is 1024 (11 bits), 
    // so each component (26 bits) uses more than its alloted 21 bits.
    // however we don't expect to span huge cubes so it is ok if we wrap
    // (every 2^21 / 2^10 = 2048 meters).
    const uint BITS_PER_COMPONENT = 21;
    const quint64 MAX_SCALED_COMPONENT = 2097152; // 2^21
    const float RESOLUTION_PER_METER = 1024.0f; // 2^10
    temp = (quint64)(point.x * RESOLUTION_PER_METER) % MAX_SCALED_COMPONENT + 
        (((quint64)(point.y * RESOLUTION_PER_METER)) % MAX_SCALED_COMPONENT << BITS_PER_COMPONENT) +
        (((quint64)(point.z * RESOLUTION_PER_METER)) % MAX_SCALED_COMPONENT << 2 * BITS_PER_COMPONENT);
    return qHash(temp, seed);
}
```

Now once you've done that you can just use QHash<const glm::vec3&, VoxelInfo>...