DegreeOfFreedom class

This pull request introduces the DegreeOfFreedom class which serves as a proxy class for getting/setting the data (e.g. position, velocity, acceleration, force, limits, etc) of individual generalized coordinates (aka degrees of freedom). This pull request also gives names to each degree of freedom and allows each degree of freedom to be accessed by name. The name of each degree of freedom in a given Skeleton is kept unique by the NameManager class.

By default, each degree of freedom is given a name based on the name of the joint it belongs to. For SingleDofJoints, their single dof is just given the same name as the joint itself. For MultiDofJoints, the dof is given a name with the pattern "\<joint_name\>_\<affix\>" where "\<joint_name\>" is simple the name of its joint, and "\<affix\>" indicates its role in the joint. For example, a TranslationalJoint named "joint1" will be given degrees of freedom with the following names: "joint1_x", "joint1_y", and "joint1_z".

The user can rename any DegreeOfFreedom at any time, however names that match already existing DOF names will be altered by the NameManager to prevent a lookup conflict.

When the user changes a joint name using Joint::setName(~), they are given the option of whether or not to have the joint's degrees of freedom automatically renamed as well (default is true).

Something to consider: Currently, if the Skeleton's Joint NameManager needs to change a joint's name to prevent a naming conflict, it will also rename that Joint's DegreesOfFreedom to match the new name. This could potentially wipe out custom names that the user might have given to that Joint's DegreesOfFreedom. Should we have a flag that the user can set to prevent this behavior?
I was debating whether or not to do that. I decided not to because the Skeleton is responsible for DOF name management (because each DOF in the skeleton must have a unique name), so accessing DOFs by name should be done through the skeleton.

Having the joints also keep track of DOF names seems redundant. And if we gave the joint class a function that uses the skeleton to look up DOFs it could be strange/confusing if someone asks a joint for a DOF that belongs to another joint.

In my mind, the thing that makes the most sense is asking the Skeleton for access to a DOF if you want to access by name, and you should only go through the Joint to access a DOF if you want to access it by its index within that Joint.

Let me know if that doesn't make sense.