* In JSDoc, resolve import types as values too
This is something that we probably should have been doing for some time.
Fixes#26049
* Fix whitespace lint
* Only bind module.exports if no local definition exists
Note that this uses `lookupSymbolForNameWorker`, which is really a
best-effort check since it only knows about symbols that it has already
encountered.
As a side-effect, even when `module` is bound as part of a
`module.exports` reference, it only declares it once instead of one
declaration per reference.
* Only type module.exports inside module files
It is an error inside script files, but the binder sometimes creates a
ModuleExports symbol because we doesn't know whether we have a commonjs
module until after binding is done.
* Only bind module.exports in a commonjs module
Note that this, too, is a best-effort check since evidence of
commonjs-ness may be found after a *reference* to module.exports. (A
reference to module.exports alone is not enough evidence that a file is
commonjs. It has to have an assignment to it.)
* Support the JSDoc @enum tag
`@enum` is used on a variable declaration with an object literal
initializer. It does a number of things:
1. The object literal has a closed set of properties, unlike other
object literals in Javascript.
2. The variable's name is resolvable as a type, but it just has the
declared type of the enum tag.
3. Each property's type must be assignable to the enum tag's declared type,
which can be any type.
For example,
```js
/** @enum {string} */
const Target = {
START: "START",
END: "END",
MISTAKE: 0, // error 'number' is not assignable to 'string' -- see (3)
}
Target.THIS_IS_AN_ERROR; // See (1)
/** @type {Target} See (2) */
var target = Target.START;
```
* Fix lint, add new test case, update API baselines
* Fix#25954 - Always retain export modifier if default modifier is present
* Also fix an issue with scope markers in ambient modules not affecting the modifiers required
comparable to the original.
Also improve the error message for implicit conversion of a symbol to a
string in a template literal, which previously shared the error message
with type assertions.
Fixes#25539. Addresses #25870.
* Split getWidenedTypeFromJSSpecialPropertyDeclaration
1. Handle this-property assignments
2. Handle other special property assignment
I have only started simplifying [2].
* Split into two passes
1. Look for jsdoc
2. Look for type of initializers
Both can be broken into their own functions.
* Break into two functions
* Move back to original function and single loop
Then, convert the 2 extracted functions to reduce-style functions that
take state and return the updated state.
* Cleanup suggestions from review
