Resolve with -lib in TypeScript lib lookup via node-style resolution

[orta]

Fixes #45993

#45771 introduced a way to write something like:

{
  "dependencies": {
    "@typescript/dom": "npm:@types/web"
  }
}

This PR changes that to be:

{
  "dependencies": {
    "@typescript/lib-dom": "npm:@types/web"
  }
}

Thus the node-style resolution for:

• lib.dom.d.ts -> @typescript/lib-dom
• lib.dom.iterable.d.ts -> @typescript/lib-dom/iterable
• lib.es2015.symbol.wellknown.d.ts -> @typescript/lib-es2015/symbol-wellknown

If you made a package which just sets up @typescript/lib-es2015/symbol-wellknown.d.ts without @typescript/lib-es2015/index.d.ts, then es2015 would still resolve to the TypeScript hosted version.

[andrewbranch]

This looks good, though it does make me consider, why do any transform on the lib file name at all? Package names can have dots, so there’s no reason our lookup name can’t be @typescript/lib.dom.d.ts, and then we wouldn’t have to do any of the name parsing.

[andrewbranch]

Maybe leaving on the .d.ts would look confusing to some people (though it’s not actually ambiguous), but I’d be tempted to at least leave the dots instead of dashes. I don’t guess it really matters, though.

[orta]

I think it's more about the form factor for how I think people would use it - for dom that means we can ship dom and dom.iterable correctly in a single package, instead of via 2 separate npm packages

The same would then apply for 'my runtime's version of es2018' which you can opt-in specific files.

[andrewbranch]

Ah, I forgot about that 👍