Handle PSR-4 path lists in getPrimaryNamespace()

[dereuromark]

A PSR-4 namespace mapped to a list of paths ("Foo\\": ["src/", "lib/"]) next to a second namespace made getPrimaryNamespace() raise "Array to string conversion". Composer's error handler turns that warning into an exception, so the autoload dump of the whole application aborts.

Each entry is now cast to an array before matching. The first matching namespace still wins, as with array_search() before.

Reduced from the original version: the absolute plugin-paths and quote escaping changes are dropped, the test and metadata cleanup went in with #88.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.46%. Comparing base (a8eddad) to head (0f278e2).

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x      #87      +/-   ##
============================================
+ Coverage     82.35%   82.46%   +0.11%     
- Complexity       48       50       +2     
============================================
  Files             1        1              
  Lines           153      154       +1     
============================================
+ Hits            126      127       +1     
  Misses           27       27              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ADmad]

A PSR-4 namespace mapped to a list of paths ("Foo\": ["src/", "lib/"]) next to a second namespace made getPrimaryNamespace() raise "Array to string conversion" and reject the package, which aborts the autoload dump.

Do we really need support for multiple auto load paths? BasePlugin::getClassPath() will always return only the "src" path.

An absolute entry in plugin-paths was written to cakephp-plugins.php but got no PSR-4 autoload entries, because preAutoloadDump() prefixed it with the application root. Both hooks now resolve paths through getFullPath().

Only paths relative should be supported for plugin-paths IMO. One can always symlink a folder within the project if they need to load plugins from external locations (which already works currently)

A single quote in a plugin name or path produced an invalid cakephp-plugins.php.

Since the plugin name and namesapce are based on folder name, are such plugins even usable in practice?

[dereuromark]

No idea, but those adjustments were free basically, so I thought it would save another edge case bug report in the future ;)

[dereuromark]

Release notes are ready, either way. We can easily drop things again.

[ADmad]

I would rather not add additional code and tests to mitigate hypothetical situations which are extremely unlikely to occur in practice. No one has reported an issue for any of these cases.

[dereuromark]

Fair on the absolute paths and the quotes, I'll drop those. The test and metadata cleanup is split out into #88.

The path-list one is a crash rather than feature support though: Composer's error handler turns the "Array to string conversion" warning into an exception, so a single plugin with that autoload shape breaks composer dump-autoload for the whole app. Would a two-line guard that just skips array entries be ok?