Allow Composer Dependencies to be scoped

### Description

I would like to see our plugins not conflict with code in a project and act more isolated. When requiring a `create-wordpress-plugin`-based plugin, you're also including all the Composer dependencies that come with the plugin (especially if you require it with Composer!). This shouldn't be the case (and won't work if you're pushing to WordPress.org).

Plugins that are scaffolded from `create-wordpress-plugin` should have the option of a build step that will scope the plugin's dependencies and prune any dependencies from `composer.json` (we don't want to have them added back when you require the plugin). When a plugin is installed, the plugin will use the scoped plugin dependencies instead (`My_Plugin_Vendor\Symfony\Console` vs `Symfony\Console`).

h2. Acceptance Criteria
1. Plugins can be scaffolded and include `php-scoper` that will automatically scope the plugin's vendor files for release.
2. A plugin's `src` files should not be modified, only changed to reference and use the newly scoped classes (we don't want to scope the plugin's file, only vendor).
3. A developer can opt to not scope their plugin during the configuration step.
4. When a project is scoping its code, a test should be performed against pull requests that scope the project's code and then test against the plugin using the scoped-code.

Some prior art:

- https://github.com/humbug/php-scoper
- https://gatographql.com/blog/graphql-api-for-wp-is-now-scoped-thanks-to-php-scoper/#heading-php-scoper-the-easy-way
- https://github.com/Yoast/wordpress-seo/

### Use Case

When a user scaffolds a plugin they can optionally scope their vendor files to prevent any potential conflicts.