Add BVH file reader

Add a BVH reader to reader motion capture files. To see more reference on
the BVH format itself, see link at the bottom. The BVH reader reads a bvh
file and outputs a polydata file and an armature file. The polydata is in
fact the polydata obtained from the armature.

This lead to a few change in the vtkArmatureWidget and vtkBoneWidget.
In vtkBoneWidget, the RotateTail function was changed to properly update
the bone's transform. Also changing the method name to make sure that
the name is more easily understandable.
In vtkArmatureWidget, add a method to get whether a bone has any child or
not. This prevent from querying all the children just to know if there are
any. Also renaming the IsBoneParent method to IsBoneParentOf for a better
API.
The armature and bone test were updated accordingly.

ref BVH: http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html
Clean up armature loading mechanisms

There still was some legacy code in the vtkSlicerArmatureLogic that was
used (and not working) for *.arm files.
This code was removed and the method named ReadArmatureFromModel was
renamed to AddArmatureFile as it is a more Slicer-like name.
Use a storage node to read in *.vtk and *.arm files

This is the more proper way to import data in slicer. This offloads the
import code from the armature logic.

Warning, this code uses a hack to work.

Background:
When adding an annotation in the scene, the annotation logic responds to
the vtkMRMLScene::NodeAddedEvent and add a hierarchy node to the new
annotation. The hierarchy node's parent is determined by the variables
ActiveAnnotationHierarchyID from the annotation logic.
Setting the right hierarchy node parent is very important as the armature
displayable manager needs them to determine how to build the widget. If the
node hierarchy isn't right, the widget hierarchy will be wrong as well.

What was done before:
When importing an armature, to make sure new bones were added correctly,
the logic would set the ActiveHierarchyNodeID to the appropriate hierarchy
node.

What was the problem:
Two problems can be found. First, using the logic to import file is
definitely not the slicer way of doing things. Secondly, if the user
happened to click at the right time on the wrong bone, the
ActiveAnnotationHierarchyID could change and the newer bone could be added
to the wrong parent. Also, there is no way to create the proper hierarchy
node before the bone is added to the scene since hierarchy nodes need to
refer to a displayable node by ID. (Since the node isn't in the scene yet,
it has no ID). Changing the hierarchy node parent after it was added isn't
really an option as it would imply that we could support re-parenting
capabilities which would require a lot, lot of refactoring/work.

What is the solution proposed:
The solution proposed is a bit hackish. In the storage node, we create a
callback that is used only when importing data. This callback responds to
the vtkMRMLScene::NodeAddedEvent with an higher priority than the
annotation logic and does the job of creating the hierarchy node properly.
When the annotation logic is called, the hierarchy node is already created
and it doesn't need to do any further treatment.
Add support to read animations from BVH files

So far it is very simple, a slider widget is added in the GUI to be able to
change the pose of the bvh armature. The widget is only enabled if the
armature loaded was a bvh.

To make this happen, a few change were made. In the BVH reader API, some
methods were added to allow external application to retrieve either the
ParentToBone rotation at a given frame for a given bone or to apply
directly the frame to a given armature widget.

In slicer, the armature storage node is now referenced by the armature's
model. Armatures can't reference to the storage node themselves since the
class doesn't inherits from vtkMRMLStorableNode. So instead we use the
model to do it. Method were added in the armature to facilitate the access
to the storage node.
WIP