Fix @implements emit for namespaced base types

[sandersn]

Fixes #38640

Couple of outstanding questions:

1. Whether an inaccessible base type is possible -- currently we only allow type references here, which is fine for chrome-devtools, but doesn't work for the pure JS case where somebody wants to declare that they implement a class that they acquired via require -- require doesn't create a real alias today, but a value, which cannot be used for implements.
2. serializeImplementedType contains a duplicate of trySerializeTypeReference, except that it calls isTypeSymbolAccessible instead of getSymbolAccessibilityChain. Both should call the same function, and then the code should be de-duped. But I'm not at all sure whether getSymbolAccessibilityChain should be expanded or whether both should call of isSymbolAccessible.

If (1) is impossible, then I can delete a lot of error reporting machinery that I currently haven't found a way to test.

Here's some more detail:

Inaccessible base type

@implements' type reference doesn't seem to add Value to name lookup the way the rest of jsdoc lookups do. I'm not sure why yet. However, chrome-devtools is referring to types from a .d.ts or global classes, as far as I know. However, the following code should probably work too:

const C = require('m')
/** @implements {C} */
class D { }

I just don't think there's much demand for that, considering that I didn't observe much usage of @implements outside closure codebases, and if people write new jsdoc, they can work around the limitation for now by creating a type alias for the type of the class: @typedef C {typeof import('m').C}.

Duplication in serializeImplementedType

I'm going to try switching trySerializeTypeReference to isValueSymbolAccessible, and pass allowModules: false.

[sandersn]

@weswigham I decided to try isSymbolAccessible for everything, and it passes all of suite 0. What additional tests even use d.ts emit? We don't have good coverage here.

[weswigham]

If t.symbol is undefined (which is often can be), I'm pretty sure this crashes? Or makes a node which'll crash later?

[weswigham]

I like how this looks now, though I am concerned with the unguarded t.symbol reference (since it only actually exists on anonymous object types and interface types).

[weswigham]

What additional tests even use d.ts emit?

JS .d.ts emit is just the relevant conformance folder, mostly. It has a fair quantity of tests in it; but the area to cover is massive.

[TimvdLippe]

This PR appears to be approved, but not merged yet. Is there anything I could help out with to get this over the line? Not sure how best we could test this in our repository, I assume we need it packed for that?

[sandersn]

Sorry, casualty of some urgent internal work that came up. I'll see if I can address @weswigham's comment about undefined t.symbol.