Connect prototype members across files

[eseliger]

Treat object literals assigned to Constructor.prototype as members of the constructor when generating SCIP symbols. This gives the prototype object, method declarations, function-valued properties, and data properties stable constructor-owned symbols that connect to references in other files without dangling intermediate locals.

Fixes #409.

[christoph-sg]

This appears to cover only whole-object replacement (C.prototype = { ... }). The equally common C.prototype.method = function () {} and C.prototype.value = … forms still fall back to local symbols. Could we add cross-file snapshot cases for direct dot-property assignment and Object.assign(C.prototype, …)?

I think if we're doing this, we should also cover those common variants to avoid surprises (the first 5 in this table)

Pattern	Covered?
C.prototype = { method: function () {} }	Yes
C.prototype.method = function () {}	No
C.prototype.value = 1	No
C.prototype["method"] = fn	No
C["prototype"] = { method() {} }	No
Object.assign(C.prototype, { method() {} })	No
Object.defineProperty(C.prototype, "method", …)	No
C.prototype = Object.create(Base.prototype, …)	No

[eseliger]

Object.assign(C.prototype, { method() {} }) and C.prototype = Object.create(Base.prototype, …) don't seem to be supported by Typescript itself. We could implement this ourselves, but that's a bit more scope. I think covering the rest and being feature-equivalent would be a good win. WDYT? Pushed support for those.

[christoph-sg]

I think covering the rest and being feature-equivalent would be a good win. WDYT? Pushed support for those.

Yeah that's exactly what I meant with

I think if we're doing this, we should also cover those common variants to avoid surprises (the first 5 in this table)

Thanks, this looks great!