WMTS Support addition
gcebelieu is a new cesium contributor.
WMTS support for 1.01 release in CHANGES.md
JSHint errors fix
revert changes to revert
renaming WMTSImageryProvider into WebMapTileServiceImageryProvider
default parameters management review.
Do really delete WMTSImageryProvider.js and WMTSImageryProviderSpec.js
Addition for what is supported or not by WebMapTileServiceImageryProvider (cf. https://github.com/AnalyticalGraphicsInc/cesium/pull/1988/files#r15667738)
rename WebMapTileServiceImageryProviderSpec.js
writing Spec Stuff for WebMapTileServiceImageryProvider
adding getter for "format" property.
removing unused variable defaultCredit
Minor tweaks to WMTS provider.

* Clean up documentation slightly.
* Rename `tms` constructor parameter to `tileMatrixSetID` to avoid abbreviation.
* Use a USGS WMTS server in the example in the docs instead of the French one, because the USGS one does not require a key.
* Add WMTS example to Sandcastle "Imagery Layers Manipulation" example.
Fix typo.
Data fix for glTF 0.8
Fix SceneTransforms.wgs84ToWindowCoordinates for SCENE2D.
Fix ReferenceProperty circular event

Since ReferenceProperty registered for the changed event of the collection it is inside of,
it can generate a circular raiseEvent call that ultimately leads to a stack overflow.
We add a boolean to keep track of whether we raised the event we are in and ignore subsequent calls until we exit.
Add unit tests, fix scene.morphTo* to work with unit tests.
Use PolylineCollection for time-dynamic polylines

In order to keep feature parity between static and time-dynamic polylines,
PolylineGeometryUpdater was using PolylineGeometry to render lines that
were changing every frame.  Obviously this generated a lot of garbage and
would kill performance when using a lot of time-dynamic lines (like the d3
demo does).  In order to improve performance, I've updated the dynamic
lines to use PolylineCollection instead; which greatly improves performance.

The only feature PolylineGeometry has that PolylineCollection lacks is
per-vertex colors; but since the DataSource layer doesn't expose that feature
yet; this is okay for now.  Of course when we have dynamic buffers,
this problem should just go away.