Fix composer-required plugin semantics

[hanneswernery]

This PR does two things.

(1)

When installing a plugin to the custom/plugins directory, Shopware will then try to verify that Shopware's main composer vendor/ folder contains all dependencies specified in that plugin's composer.json. This is problematic since plugins may be distributed as e.g. ZIP files which ship their own vendor/ directory, which may include additional libraries. In this case, even though the plugin ships its own dependencies, Shopware will refuse to install the plugin.

This PR fixes this issue by only validating composer dependencies for plugins which are managedByComposer. This way, Shopware validates plugin dependencies if and only if the plugin is installed into the Shopware installation using composer.

(2)

shopware/development's composer.json adds custom/plugins as an additonal repository: https://github.com/shopware/development/blob/55cc7cb310d16e0bc614bfcfe108e0686ccbe586/composer.json#L9-L15

This allows shop administrators to composer require plugins which reside in custom/plugins into Shopware's vendor/ directory, resolving the plugins' dependencies and generating optimized classmaps in the process. However, if you try this and then run bin/console plugin:refresh, this will fail with a unique constraint violation because the PluginFinder tries to add the plugin from custom/plugins as well as from the vendor/ directory.

To fix this, this PR resolves these conflicts by always preferring plugins installed into the vendor/ folder over those installed in custom/plugins.

[ghost]

Danger run resulted in 1 warning; to find out more, see the checks page.

Generated by :no_entry_sign: dangerJS

[fixpunkt]

Looks good. Once you've manually tested everything again and verified that Shopware's tests pass, you can open the PR against https://github.com/shopware/platform!

[fixpunkt]

Upstream PR is here: https://github.com/shopware/platform/pull/25