@overload doesn't check implementation against overload signatures

[DanielRosenwasser]

#51234 introduced a new @overload tag, but it doesn't have the same type-checking rules as TypeScript's overloads.

Namely that we ensure that for each overload, the implementation signature is assignable to that overload, allowing the return type to be bidirectionally assignable.

If we want the same results in checkJs, then the following should error:

// @ts-check

/**
 * @overload
 * @param {number} x
 * @returns {number}
 */

/**
 * @param {string} x
 * @returns {string}
 */
function wut(x) {
    return String(x);
}

wut(123).toFixed(2);

[RyanCavanaugh]

Is this desirable? I feel like our implementation/overload checking logic is so full of holes that it's not clear that JS Doc users would really benefit from it.

[DanielRosenwasser]

Do you think JSDoc users want stricter checking or looser checking? If stricter, we can tighten the rules.