Fix Octree and Constraint Generation w.r.t. local poses

The recent change to collision detection producing local positions
instead of global positions effected the way localizations are created
during contact constraint generation. Since the "local" position during
collision detection is local to the collision representation, it can't
be directly copied to the localization. The localization is "local" to
the physics representation. This change transforms the Location from the
collision representation's coordinate frame to the physics
representations coordinate frame before creating a localization in
ContactContstraintGeneration.

Also, using local positions broke the way the Octree creates contacts in
OctreeDcdContact. This change transforms the local contact position from
the individual nodes of the octree to the local position of the octree.
Slight change local position in ContactContraintGeneration

Need to go through the element pose instead of the global pose when
transforming the local collision Location to the local physics Location.
This is because of the difference between the collision representation
using the temperary but current element pose needed for collision
detection, while the phyics getPose uses the old, but final element pose from
the last iteration. This just short circuits these and goes through the
local poses only. This doesn't work if the collision representation and
physics representation are in different elements, but we already assume
this in other places.
Unitest that checks Octree Contact location

Added a unit test that verifies the rigidLocalPosition is valid when
doing Octree collision detection. This highlights the bug fixed in
58d180df3437c3dcf042dbcb8e0073bce47acc4e.
Unit test for contact contraint generation and local poses

This unit test checks to make sure that the position of the location
produced by collision detection matches the position in the localization
produced by contact contraint generation. This highlights a bug fixed in
58d180df3437c3dcf042dbcb8e0073bce47acc4e and
191a21675211dc8cae14166bb10741b541e20650.
Updated comments in ContactConstraintGeneration

Updated the doxygen comments in ContactConstraintGeneration and added
some debug info to the ContactConstraintGenerationTests.
Make getNode() return last valid node if requested
Meshes should not use the display list, they can get too big
Use mass center in addGeneralizedForce calculations

Use the center of mass of the RigidRepresentation instead of 0,0,0 for
adding external generalized forces.
Use the center of mass in the bilateral 3d contraint

This uses the center of mass instead of 0,0,0 of the rigid
representation when building the bilateral 3d constraint.
Tweak VTC parameters in Stapling example

Tweak the vtc parameters in the stapling example for better performance.
The VTC auto-calculates stiffness and damping parameters, but it assumes
the physics manager is running at 1000Hz. Since the stapling example
only runs at about 100Hz, these parameters need to be manually set for
better behavior.

Also, adjust the vtc parameter calculation to account for the attachment
point, when it calculates the moment of inertia.
Enable deletion of triangles from the datastructure
Make arm unstapleable in Stapling example

Since the staples tend to rotate alot when stapled in the fixed arm,
disable stapling there. But, still allow stapling in the wound where the
behaviour is much better.
Correct setInertialForces in VTC

The behaviour of the setInertialForces for the vtc is modified. Before
it incorrectly changed the calculation of the attacment point velocity.
Now, the vtc adds an external generalized force to the physics
representation at it's center of mass when calculateInertialForces is
off, and adds an external force at the attachment point when it is on.
This is the expected behaviour.
Set rate of PhysicsManager to 100Hz in Stapling example

Set the rate of the physics manager in the stapling example to 100Hz.
This is closer to the actual update rate. As a result, the vtc behaves
much better and the tissue behaves more realistically. This is because
before the physics was being run as if it was at 1kHz, but it wasn't. So
the mechanical properties were incorrect. As a result, the default vtc
parameters can be used again (although the defaults are tuned a bit
here).

Also, turn off the inertial force on the vtc in the stapling example.
This gives nicer tool behaviour.
Fix header guards in Stapling Example and whitespace in VTC
Adapt classes that process all triangles to take deleted triangles into account
Add RenderTest
Documentation
Check if density is > 0 when updating Rigid's properties

Before updating the properties of a rigid representation, check to see
if the density is > 0. This mimics the behavior of the
RigidRepresentationParameters before they were moved into
RigidRepresentationBase.
Merge branch 'master' into fix/local-poses

Conflicts:
	SurgSim/Physics/ContactConstraintGeneration.cpp
	SurgSim/Physics/ContactConstraintGeneration.h
	SurgSim/Physics/UnitTests/ContactConstraintGenerationTests.cpp