typings: share AsyncWrap and HandleWrap types

[leah-1ee]

Some internal binding typings currently flatten methods inherited from native
base classes into each derived class.

For example, the native hierarchy for SignalWrap is:

Native class	Direct JS-visible members
AsyncWrap	getAsyncId, asyncReset, getAsyncContextFrameForDebuggingOnly, getProviderType
HandleWrap	close, hasRef, ref, unref
SignalWrap	start, stop

The current Signal typing directly declares the HandleWrap methods, while
the native inheritance relationship itself is not represented.

This change introduces reusable AsyncWrap and HandleWrap interfaces and
models the same hierarchy in the typings:

export interface AsyncWrap {
  getAsyncId(): number;
  asyncReset(resource: object, executionAsyncId?: number): void;
  getAsyncContextFrameForDebuggingOnly(): unknown;
  getProviderType(): number;
}

export interface HandleWrap extends AsyncWrap {
  close(callback?: () => void): void;
  hasRef(): boolean;
  ref(): void;
  unref(): void;
}

class Signal {
  constructor();
  onsignal?: (signum: number) => void;
  start(signum: number): number | undefined;
  stop(): number;
}

interface Signal extends HandleWrap {}

The same structure is applied to TraceSigintWatchdog.

This makes binding-specific members easier to distinguish from inherited
members and reduces repeated declarations.

No new runtime APIs are introduced. The AsyncWrap methods added to the
static types of Signal and TraceSigintWatchdog are already available
through the native prototype hierarchy.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.