Support standalone plugin development

[ppolo99]

Summary
Extend vip dev-env to support standalone plugin development — developing a plugin in isolation from any one VIP application, while still benefiting from VIP-specific platform features (page cache purging, Photon fronted images, etc.) that wp-env and WordPress Playground don't replicate.

Problem
Today there's no first-class way to use vip dev-env for developing a plugin outside the context of a specific VIP application. This is particularly important for "group" plugins - plugins that are shared across multiple customer applications and that interact with VIP-specific platform behaviors. For these to be tested and maintained properly, they need to be developed in isolation from any single application.

Proposed solution
Extend vip-dev-env.yml (and the CLI) to allow app to be set to something like demo, which would:

• Pull the VIP skeleton repo automatically
• Allow plugins (or similar artifacts) to be mapped from the current parent directory into the environment, in a manner similar to .wp-env.json's plugin mapping

This would give developers the ergonomics of wp-env while retaining VIP platform fidelity.

Current workarounds

1. Check out the plugin into an existing app's plugins/ directory. Simple, but couples the plugin to that application. Plugins developed this way tend to have issues later because they weren't developed in isolation.
2. Local build + VIP skeleton repo + Node watcher that copies changes into the skeleton's plugin directory. Works but is involved, has to be set up per plugin, and is fragile compared to a native CLI option.

Use case / impact
Enables clean, isolated development and testing of shared plugins that depend on VIP-specific behaviour, without coupling them to a specific customer codebase. Reduces per-plugin setup overhead and improves reliability of plugin releases that ship across multiple customers.

Originated from Pendo request.