feat(versioning): use native custom element lifecycle

[nolanlawson]

Details

This is a 4-part PR.

Part 1: basic scaffolding for versioning (#3350)
Part 2: using it in the template compiler (#3351)
Part 3: using it in the runtime (this PR)
Part 4: using it in the Babel plugin (#3354)

I decided to fix #3198 as an example of using API versioning in the client side. Here we have a version number associated with a compiled component, and then individual components may run with native custom element lifecycle or not.

I also went ahead and modified the Karma tests to run with different API versions: API_VERSION=59 yarn test. I think this is simpler than using individual feature flags anyway.

Fixes #3198

Does this pull request introduce a breaking change?

• ✅ No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

• ✅ No, it does not introduce an observable change.

GUS work item

W-12566318

[nolanlawson]

TODO: I should probably add Karma tests for having mixed v58 and v59 components in the same tree, and confirm that they can use synthetic vs native lifecycle independent of each other.

Edit: added the test, and good thing I did! There was a bug when you had mixed API versions between parent and child components. 😅

[nolanlawson]

I would love to use the integer type here, but I could not get it to work, and I figured there's little point in debugging Circle CI oddities since we may move away from Circle CI anyway.

[nolanlawson]

What I'm doing here is a known perf regression (adding the connectedCallback / disconnectedCallback to the prototype). But there is no other way to solve this, so this is just a hit we have to take.

We may be able to solve the perf regression if we do #3202 someday.