Allow namespaces in plugin entrypoints named after the plugin

[kadamwhite]

This expands the existing exceptions for "main files" (functions.php, plugin.php) to be able to recognize plugin entrypoints named after the plugin itself, e.g. query-monitor/query-monitor.php instead of plugin.php.

Supersedes #343

[kadamwhite]

Noting here explicitly: this marks a departure from the existing coding standard requirement that plugin entry points be named plugin.php, which I argue is unhelpful exceptionalist versus the established community pattern of naming it the same as the plugin folder.

In many cases the areas that our projects have organically drifted from our coding standards show reveal where we need to improve messaging or communication about why we think we should hold to a singular pattern. However, in this case I feel it is pragmatic to permit the external standard that gets used regularly in practice alongside the plugin.php convention.

[rmccue]

This original behaviour was intentional, so if we're going to change it, we should consider what and why to change our standards; that change should happen in the documented standards before/simultaneously with the standards here.

Our standards require the use of a commonly-named entrypoint across our projects:

• For themes, functions.php (enforced by WordPress)
• For plugins, plugin.php
• For other Composer packages (originally Altis modules but could be anything), load.php

This, and other naming standards like inc/, are designed to improve the ability for anyone to pick up a given piece of code and know where to start in order to browse and grok the project. This consistency is pretty rigid for a reason - so that onboarding is easier.

For plugins specifically, you can call them anything you want - the same-as-directory pattern is common in the ecosystem - as WP scans for all files with a plugin header. It's also not uncommon for these directories to be renamed, either when installed by a build system or for other conflict-avoidance reasons; the directory name may also not match the repository name.

The idea of picking one name here was specifically to make it predictable. Every plugin can have a package.json, a composer.json, a inc/, and a plugin.php - making this always the same removes unpredictability and improves grokkability of projects.

Noting here explicitly: this marks a departure from the existing coding standard requirement that plugin entry points be named plugin.php, which I argue is unhelpful exceptionalist versus the established community pattern of naming it the same as the plugin folder.

We already deviate pretty substantially from the wpcs standard, and I'd expect most plugins to fail our checks anyway - that's because we generally hold ourselves to a higher standard. In this case, it's also because we're aiming to achieve things (as noted above) that most of the ecosystem don't really care about.