Function expressions in a property assignment of a prototype object should be methods, not nested classes

/** @class */
module.exports.C = function() {
  this.x = 1
}
module.exports.C.prototype = {
  m1() {
    this.a = 1
  },
  m2: function() {
    this.b = 2
  }
}
var c = new module.exports.C()
c.a
c.b

Expected behavior:
c.a and c.b both work.

Actual behavior:
Only c.a works; c.b says that 'd' does not exist on type 'C'. There's also an error on this.b = 2 when noImplicitThis: true.

bindThisPropertyAssignment needs to understand that function expressions might be part of a property assignment in an object literal. The code to handle this will probably look like this:

                    // For `{ x: function() }` should modify the object literal's members, not behave like a fresh class (as long as it doesn't have @class on it)
                    if (isPropertyAssignment(thisContainer.parent)) {
                        // wow I hope those parent pointers are set!
                        const containingClass = thisContainer.parent.parent;
                        const symbolTable = containingClass.symbol.members!;
                        if (hasDynamicName(node)) {
                            bindDynamicallyNamedThisPropertyAssignment(node, containingClass.symbol);
                        }
                        else {
                            declareSymbol(symbolTable, containingClass.symbol, node, SymbolFlags.Property | SymbolFlags.Assignment, SymbolFlags.None, /*isReplaceableByMethod*/ true);
                        }
                        break;
                    }

I expect this to break a lot of tests, but it didn't. However, I haven't tried it on the user tests yet.

Start with the reproduction in the issue and inspect bindThisPropertyAssignment, especially how function expressions inside prototype object property assignments are handled. Verify the behavior with the shown example under noImplicitThis, including whether both c.a and c.b work and the reported diagnostic is gone.