feat(test): add vitest setup and widget container tests

[tearf001]

Description

This PR fixes the issue where multiple GridStack instances would crash when using the React integration due to shared state in the static GridStack.renderCB callback (#2937).

Problem: The static GridStack.renderCB was being shared across all GridStack instances, causing widget container references to be mixed up between different grids. This led to crashes and incorrect behavior when multiple grids were present on the same page.

Solution: Implemented a WeakMap-based approach to store widget containers separately for each GridStack instance:

• Added a gridWidgetContainersMap WeakMap that uses the GridStack instance as the key
• Each grid instance now maintains its own isolated widget container map
• The WeakMap ensures automatic memory cleanup when grid instances are destroyed

the fix snippets:

// Before: All grids shared the same widget containers
GridStack.renderCB = (el, widget) => {
  widgetContainersRef.current.set(widget.id, el); // Shared state
}

// After: Each grid has its own container map
GridStack.renderCB = (el, widget) => {
  if (widget.grid) {
    let containers = gridWidgetContainersMap.get(widget.grid);
    if (!containers) {
      containers = new Map();
      gridWidgetContainersMap.set(widget.grid, containers);
    }
    containers.set(widget.id, el); // Instance-specific state
  }
}

This ensures that multiple GridStack instances can coexist safely without interfering with each other's widget management.

Checklist

• All tests passing (yarn test)

Additional notes:

• Added comprehensive unit tests using Vitest to verify the WeakMap functionality
• Tests cover: multi-instance isolation, proper cleanup, and widget container management
• The solution maintains backward compatibility while fixing the multi-instance issue

[adumesny]

guess you're using npm instead of yarn, which I guess is fine...

[adumesny]

thank you for the changes. but those will get blown away when the POSSIBLE pending React changelist comes in, so wondering if you could look at #2938 as well and give you take on that other aproach ?