architecture notes about custom setters, watch(), and widgets.register()
Button: update test to use native accessors not set() and get()
widgets.register() and native ES5 setters

register()
----------
Create widgets.register() method to be used in place of dojo.declare() for
creating widgets.  register() does the introspection work formerly in
_WidgetBase._introspect() method.

ES5 setters
-----------
register() supports native getters/setters on top of old widget architecture of
_setFooAttr methods.
Hopefully in the future, dcl() will support native getters/setters, and then this
introspection code looking for _setFooAttr properties and dynamically creating accessors
can be removed.

_WidgetBase.get() removed, and set() changed to just do hashes.

The auto-mapping of widget attributes to the widget DOMNodes is complicated, and
no longer works: myWidget.disabled = true won't do anything unless there's a custom
setter for disabled.

Eventually widgets will be extensions of HTMLElement, so that any widget properties
that map to the top level DOMNode will be handled automatically.
But for properties that map to a subnode of the widget, like tabIndex mapping to
this.focusNode (where this.focusNode is a descendant of this.domNode), they will need
custom setters, either as part of the widget definition or generated dynamically.

watch()
-------
Watch() support: Generally any property that might be watched should have a custom setter
in the prototype.  You can declare a simple custom setter like:

	_setFooAttr: null

That will internally generate a custom setter of _setFooAttr: function(val){ this._set("foo", val); }.

If you ask to watch() a value without a custom setter, watch() will create one on the fly.

widget lifecycle changes w.r.t. custom setters
----------------------------------------------
On widget creation, only call custom setters for widget parameters,
In V1, it called the custom setters for properties not passed into the constructor,
as long as the default value was truthy (see https://bugs.dojotoolkit.org/ticket/7381)

Also, the custom setters are called before rendering.
Previously they were called after rendering.
Added a runAfterRender() helper method for custom setters that need to register code to
be run after the DOM is created.

It's unclear if we want to call the custom setters before or after buildRendering().
For now it's calling the custom setters first, because they are called implicitly
when the properties are mixed in (before the postMixInProperties() call).
architecture notes on native accessors, _WidgetBase.watch(), and widgets.register()