JS: Split module exports into a local and global variant

[asgerf]

ExportDeclaration.getSourceNode and .exportsAs were global because they look through re-exports.

This PR splits these into a "direct" version that is local and ignores re-exports, and a non-direct version that is global and looks through re-exports.

One of the use-cases for the direct version is for API graphs to make a local over-approximation of the set of def-nodes we need, so that API::Node can become local.

[Copilot]

Pull request overview

This PR refactors the module export system to distinguish between direct exports and re-exports, supporting better locality analysis for API graphs. The changes split exportsAs and getSourceNode into "direct" variants (local, ignoring re-exports) and non-direct variants (global, looking through re-exports).

• Added exportsDirectlyAs and getDirectSourceNode predicates for local export analysis
• Introduced reExportsAs and getReExportedSourceNode in ReExportDeclaration for tracking re-exported values
• Refactored type-only export handling and simplified OriginalExportDeclaration

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment says "this re-export destination" but it should say "this re-export declaration" instead. The term "destination" is confusing here - the declaration is the source of the re-export, not the destination.

[tausbn]

Looks good to me! The uppercase E in ReExport kind of makes my eye twitch, but I'm not going to complain loudly about it. (I would prefer Reexport -- or Reëxport if we want to go full New Yorker.)