Added double sided to the createMesh in the threejs driver
Added nodes to test the new threejs primitives
Change emissive to ambient in CreateMesh material.

Refs #1889
Change sandtable to use threejs by default

Refs #2087
0.6.10 rollback for reintegration
0.6.10 CHANGELOG.md modifications
0.6.11 Version Rollover
Update the cookbook index page to give a description of the cookbook. Fixes #2113.
Update kernel api links. Fixes #2067.
Editor updates navigation properties correctly.  Specific to camera/navigation at 200ms update rate.  Redmine Task: 1626
Update component Rakefile to build docs for child directories of vwf.example.com and update doc syntax to properly display. Fixes #1779 and fixes #1629.
Added tolerance test for public/test/transformTo app (exercises transformBy, transformTo, worldTransformBy, worldTransformTo).  Redmine #1934.
test/worldTransform determined to no longer be applicable.  Removed.  Redmine #1932
Remove static ID references from HTML overlay documentation. Fixes #1780.
cleaned up test/transformTo, removed unused parameters to clean up error logging.
Delete primitives app as it contains nothing but a light definition. Add index files for models and primitives. Fixes #777.
Don't remove reflector messages in `setState` sent after the action.

When updating the message queue to match the incoming specification,
`setState` previously cleared the queue except for messages with a
`respond` field. But that would delete messages sent after the
`setState` that arrived before it finished executing. Those messages
apply to the new state and should be retained.

The correct process is to delete all future messages, including any
generated during the `setState` since the incoming queue contains the
correct messages for the new state, delete any reflector messages that
arrived before the `setState` but were scheduled to execute at a later
time, but retain any reflector messages that arrived after the
`setState`.

Fixes #2122.
Schedule future actions in front of reflector actions at the same time.

Previously, if future and reflector actions were placed in the message
queue with the same execution time, they would be arranged in order of
arrival. But this would leave the queue in an indeterminate state. Since
reflector messages arrive at different clients at different times,
clients wouldn't order these sequences consistently.

Additionally, it's probably expected that when an action generates a
future action at delta time 0, the new action will run before a new
external action executes--even if an external action for the current
time has already arrived.

Now, the message queue is sorted first by time, as before, then by
origin to place future actions in front of reflector actions, then by
arrival order, as before. This ensures that a sequence of future
actions, including one that generates new actions for the same time,
will always run to completion before a reflector action executes,
regardless of whether the external action arrives before, during or
after the sequence starts executing.

Fixes #2123.
Updated the Rakefile to remove HTML files autogenerated from a previous build.  Fixes #2065
Updated Browser Requirements from Tested and Support Browser versions.  Added notes about IE10 limited support, and potential IE11 WebGL support.  Fixes #2069