Fixes for type parameter name resolution in JS

[sandersn]

1. check for expando initializers in resolveEntityName

... when resolving type parameters in a prototype property assignment
declaration. For example, this already works:

/** @template T */
function f(x) { this.x = x }
/** @returns {T} */
f.protototype.m = function () { return this.x }

This now works too:

/** @template T */
var f = function (x) { this.x = x }
/** @returns {T} */
f.prototype.m = function () { return this.x }

Fixes #26826

2. Lookup type parameters on prototype-assignment methods

…In the same way that they're looked up on prototype-property methods.

That is, this previously worked:

/** @template T */
function f() { }
/** @param {T} p */
f.prototype.m = function () { }

And this now works too:

/** @template T */
function f() { }
f.prototype = {
  /** @param {T} p */
  m() { }
}

Note that the baselines still have errors; I filed #26831 to follow up on those.

Fixes #24230

[ghost]

This isn't working when calling the method:

/**
 * Should work for function declarations
 * @constructor
 * @template {string} K
 * @template V
 */
function Multimap() {
    /** @type {Object<string, V>} TODO: Remove the prototype from the fresh object */
    this._map = {};
};
 /**
 * @param {K} key the key ok
 * @returns {V} the value ok
 */
Multimap.prototype.get = function (key) {
    return this._map[key + ''];
}

/** @type {Multimap<"a" | "b", number>} */
const map = new Multimap();
const n = map.get("a");

At the last line, there's an error that "a" isn't assignable to K, and n is of type V instead of number.

[sandersn]

only works for methods, not properties with function values. That is, get: function(key) ... doesn't work

[sandersn]

@andy-ms Oof, yeah, that's a bigger limitation of the types we create for JSDoc generics. They're not really generics, and aren't instantiated using the normal instantiation code. That's not related to this fix — you'll see that the type is always just Multimap, although it means that the overall scenario doesn't work. Given that I'll be on vacation and DefinitelyTyped most of the rest of this release, I'm going to create a separate issue to track fixing generic types.

(Note that the 3.0 behaviour is that instances of Multimap are completely unaware of type parameters, so that n: any in your example.)

Filed #26883 to track this.