Introduction of Stateful#observe(), refs #178.

The new `Stateful#observe()` returns an observer (delite/Stateful.PropertyListObserver) that is API-compatible to [Polymer observe-js](https://github.com/Polymer/observe-js#observable). `Stateful.PropertyListObserver` has most of the features of delite/Invalidating, except event emission. I didn't see the event emission feature is actually used anywhere, but anybody who sees an actual use case please speak up. I foresee most of the use cases of event emission can be achieved by observing for properties.

Per Christophe's feedback, I also introduced delite/Observing, that serves as a higher-level API set on top of delite/Stateful and delite/Stateful.PropertyListObserver.

With delite/Observing, widgets can set up an observer for computed property and an observer for UI rendering, by the following:

```javascript
// Computed properties
this.addComputingProperties(
    "value",
    "min",
    "max"
);
// UI rendering
this.addRenderingProperties(
    "value",
    "min",
    "max",
    "message",
    "displayExtMsg",
    "fractionDigits"
);
```

Other features in delite/Stateful and delite/Observing corresponding to delite/Invalidating features are:

* `delite/Invalidating#invalidateProperties(name)` and `delite/Invalidating#invalidateRendering(name)`: `Stateful#notifyCurrentValue(name)`, which creates a pending change record even if there is no change in value.
* `delite/Invalidating#validateProperties()`: `delite/Observing#deliverComputing()`, which synchronously calls `deliver/Observing#computeProperties()` if there are pending change records for it
* `delite/Invalidating#validateRendering()`: `delite/Observing#deliverRendeirng()`, which synchronously calls `deliver/Observing#refreshRendering()` if there are pending change records for it

I made change to widgets for proof-of-concept (Intern automation seems to run fine for those changed widgets):

* deliteful/StarRating (The simplest case, only with UI rendering callback)
* deliteful/ProgressBar (A simple case with computed property callback in addition to UI rendering callback)
* delite/FormWidget, delite/FormValueWidget and deliteful/Slider (A case where property list for UI rendering callback is specified in multiple places in a widget)

The upcoming plan is:

* Once this PR looks fine for the stakeholders (and merged), change the remainder of delite/Invalidating-based widgets
* Once the team sees `Stateful#observe()` performance (for `Stateful#watch()` use case) is fine with Android device, change `Stateful#watch()` usage (esp. template code)
* Once we are ready to remove `Stateful#watch()`, stop calling `_introspect()` for properties if `Object.observe()` is natively available and Stateful-based getter/setter is not set up
why do we have a discrepancy in naming, that is deliver vs discardChanges and not either deliver & discard or deliverChanges & discardChanges which would be more consistent.