Improve @overload's interactions with constructors

[sandersn]

1. Get @overload return type for constructors in getReturnTypeOfSignature
2. No bogus implicit-any error on new calls in checkCallExpression
3. No bogus implicit-any error in constructor @overloads in getSignaturesOfSymbol

Fixes #52477 (no bug for (3), which I discovered in the process of fixing (1) and (2))

[jakebailey]

Does this test need to be written in such a way as to satisfy #52474?

[sandersn]

You mean putting all the tags into a single comment? No, this test showed that that requirement isn't feasible; the parser can't distinguish between the end of a return-less @overload and the beginning of the implementation's @params. So I reverted it and once again @overload is unlike all other jsdoc comments in checking all preceding /** comments.

[jakebailey]

Oh, so #52474 is no longer a thing, okay.

[jakebailey]

Is isJSDocConstructSignature supposed to do the check?

[sandersn]

Confusingly, JSDocConstructSignature refers to closure type syntax: function(new: SomeClass) is equivalent to TS new (): SomeClass.

The naming scheme could be better though.

[DanielRosenwasser]

@typescript-bot pack this

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 57bd245. You can monitor the build here.

[typescript-bot]

Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/145222/artifacts?artifactName=tgz&fileId=09F9A96CA0B755F016683366DA413949CFC8656248B98D4FBB7A199FA82E080C02&fileName=/typescript-5.0.0-insiders.20230202.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.0.0-pr-52577-2".;