Add support for new elements in `event-valuechange`

As discussed in #1157:

This PR adds support for two groups of new elements for `event-valuechange`, `<select>` elements with `<option>` choices, and any element with the `[contenteditable="true"]` attribute.

The `<select>` elements work nearly the same way as `<input>` and `<textarea>`, which basically checks their `value` attribute for any change.  There are some performance cheats involved in the polling loop to improve performance on IE6 without having to resort to using `node.get('value')`, and have been fully tested.

The `[contenteditable="true"]` (or `[contenteditable=""]`) elements act differently, and fires a change when their `innerHTML` property changes.  For now, there isn't support for elements that inherit `contenteditable` from a parent element.  It's something I could add, but I'm worried about the performance hit on having to search up the DOM tree to check whether or not the element has a parent node that has `[contenteditable="true"]`.  If that's something that might be useful, though, let me know, and I'll see if I can find an efficient way to do that.

This was tested on all A-grade browsers (including IE6) and passes all unit tests and manual tests for each one.  There were no performance hits even after adding the new functionality in.

The goal for this enhancement is mainly so that we can use the `valuechange` event to efficiently detect form element changes when implementing two-way data-binding later on.