Initial hot elements implementation. [Not ready to merge]

[rictic]

Two things I'd want to fix before merging:

1. This code should never show up in production (if for no other reason than it adds unnecessary bytes). What's the best way of ensuring that? Currently this uses goog.DEBUG for that purpose, which works well with closure compiler, but not anything else.
2. Need to use proxies when available, so that elements stay constructable after they've been hot reloaded.

Related to #673

[justinfagnani]

Since we don't have separate prod and dev builds, I think we need to patch in the static methods from hot-elements.ts.

[rictic]

Ideally hot-elements would live in its own package though, and optimizing out the unused hot reloading code could be done at application build time.

If we had such a mechanism we could use it in other places too, e.g. to log errors when unexpected things occur that would be too expensive to check for in production

[justinfagnani]

We're really not going to have such a mechanism though, at least any time soon. There's no standard for stripping dead code and we've seen in other packages that dev code can easily end up in prod. My only thought at the moment is that we could vend an API compatible lit-element-dev package and allow build tools to swap it in.

In the mean time, patching seems best to me.

[abdonrd]

@rictic @justinfagnani there are any plans to move this to lit-next?

[LarsDenBakker]

Thanks to @43081j we now have a HMR plugin for web dev server: https://modern-web.dev/docs/dev-server/plugins/hmr/

I created a small lit-html demo which applies some of the code of this PR to a simple base class using lit-html, just to check if this can work out: https://github.com/modernweb-dev/web/tree/master/packages/dev-server-hmr/demo/lit-html

It would be great if we could still introduce something like this before lit-next if possible.

[justinfagnani]

@rictic we should port this to 3.0