[webcomponents] defineElement should not cache lifecycle callbacks and prototype of a custom element class (#417)

During Jan F2F, Google made an argument that we need to cache the lifecycle callbacks to avoid enqueueing unnecessary items (e.g. when `attributeChangedCallback` is missing) but we (Apple) no longer think this is an acceptable behavior.

This behavior precludes authors from overriding method on a particular instance of a custom element. In order to change even a single instance's behavior, you would have to define a new custom element or make the element call its own delegate method which is unnecessary boilerplate.

In addition, we think modern JS engines are fully capable of detecting changes in JS object's structure for optimization purposes and if Google and other implementors wanted to avoid enqueuing unnecessary items, they ought be able to implement such an optimization utilizing such a capability in their JS respective engine.

Furthermore, we don't think such an optimization is beneficial in the world with `attributeFilter` (see the issue #367) because:
 1. A custom element that doesn't use `attributeChangedCallback` should be omitting `attributeFilter`.
 2. Google representatives repeatedly stated that they believe a high performance component should be doing the work (e.g. attaching shadow root) to setup itself in `attachedCallback` (see the issue #362 for the rename) instead of the constructor in which case most of custom elements would have these callback anyway.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/417