Dynamic scene refactor

This code attempts to expose the features of Geometry & Appearances at the DataSource layer.  I don't expect this pull to be merged any time soon, I may even close it after some initial review.  This is largely so that @bagnell (and others) can look at my Geometry & Appearances usage and @shunter can comment on some DynamicScene changes I've made.  I didn't want to spend any more time documenting/cleanup until I got some sign-off.

**New Geometry overview**
I haven't added complete documentation yet, but I wanted to write up an overview of the approach.  If you need me to provide some test geojson or CZML files, just let me know.

`GeometryUpdater` is a new interface which is implemented by a class that wishes to map one of the `DynamicScene` types to an equivalent `GeometryInstance` and `Appearance`, i.e. `DynamicPolygon` is mapped to a `PolygonGeometry` backed `GeometryInstance` by the new `PolygonGeometryUpdater`.  For static data, updaters themselves don't actually create primitives, they just create geometry instances which are analyzed and batched further up the chain.  For dynamic data, each `GeometryUpdater` knows how to create a `DynamicGeometryUpdater` instance which manages a single primitive that represents that geometry from frame to frame.

`GeometryVisualizer` is a new `Visualizer` type that handles batching and management of the updater supplied instances.  It does not do much other than delegate to private helper classes, `StaticGeometryColorBatch`, `StaticGeometryPerMaterialBatch`, `StaticOutlineGeometryBatch`, and `DynamicGeometryBatch` (all of which should be self-explanatory).  These helper classes actually create primitives and handle the binning of items (i.e. colored geometry is binned into translucent/opaque categories).  GeometryVisualizer takes an Updater type in it's constructor, which means each visualizer only handles one type of geometry (by design).  This works well because it makes it easy for each geometry type to have it's own appearance, for example, EllipsoidGeometryUpdater uses the EllipsoidSurfaceAppearance, instead of the default MaterialAppearance.

One design decision I made was to treat a filled and outlined geometry as either completely static or completely dynamic.  This is less efficient in the case where one is static and the other isn't, but this almost never happens (for example, having a dynamic `numberOfVerticalLines` property for Ellipse, but static everything else).  This decision basically makes the code a lot cleaner.  We can always optimize it later if it becomes an issue. That was my approach overall, clean and complete first, optimize later.

All Geometry is created synchronously right now,  I do this because there doesn't seem to be a way to use instance attributes properly with asynchronous primitives.  You are not allowed to call `getGeometryInstanceAttributes` until the primitive is rendered and there's no event to know when the asynchronous operation is done.  Maybe I'm missing something.

We also only evaluate/iterate over instance attributes that actually change from frame to frame.  This is much more efficient than what is going on with the old visualizers in master.

**Other DynamicScene changes**

Properties now have an `isConstant` property which means the value is constant as far as simulation time goes.  The also have a `definitionChanged` event which fires if a mutable property is changed (for example, samples are added to SampledProperty).  Both of these changes are necessary in order to properly batch and managed geometry and updates.

DynamicPolygon/Ellipse/Ellipsoid/Polyline have new properties that mirror geometry options (`extrudedHeight` for example).  Their visualizers have been replaced with updatrs.

The `propertyChanged` event on  DynamicScene objects has been renamed to `definitionChanged`.  Also, the event is now raised in the case of an existing property being modified as well as having a new property assigned (previously only property assignment would raise the event).

The `dynamicObject` property which got globbed onto all primitives for picking has been removed and replaced by using the `id` property, which is the correct way to do it anyway (and didn't exist when we first wrote this).

I'm sure I forgot some things, but that should be enough info to look at this and see what's going on.  Put a breakpoint in `GeometryVisualizer.update` and then load a czml/geojson file to step through the whole things.