Comprehensive solution for potx config project:module format dependencies

I'm working on this right now. I have an initial working patch, but I need to do a bit more testing. I also have to write a patch for the l10n_drupal connector in the l10n_server module, which should be deployed alongside the patch here. I'll hopefully have both patches ready in 2-3 days.

I've modified the code to use the fully qualified name of the modules everywhere. Module names are converted to their fully qualified form when they are parsed or loaded from files, so most of the code only has to deal with the fully qualified form.

The project name is added to the .info.yml file when it's being packaged on drupal.org, so it might not be available in local modules. So, when running potx locally, the name of the top-most directory containing a .info.yml file is considered as the project name. Of course, Drupal core is an exception, because the top-most directory is named "core" and it doesn't have a .info.yml file. This is more properly handled in l10n_server where the project key in the .info.yml file is used.

I've also fixed a seperate bug in detecting dependencies in Drupal profiles, since they were being defined in the "install: " key in the .info.yml file instead of the "dependencies: " key.

A bit more cleanup.

Moving test files around. Config files need to have a corresponding .info.yml file, and should be located in one of the main module directories (modules/ , themes/ , sites/) to be detected and parsed by potx.

I've also posted a related patch for l10n_server in #3014336: Handle the project:module format for dependencies to extract translatable strings from config: the l10n_server part..

Both patches should be applied so that the project:module format can be handled on localize.drupal.org.

I applied both patches to https://basic-localize.dev.devdrupal.org/translate/projects/drupal/releases and re-parsed 8.6.3. Compared to https://localize.drupal.org/translate/projects/drupal/releases, there are the same number of files, but 202 less strings. And the “basic page” example is still not found: https://basic-localize.dev.devdrupal.org/translate/languages/nb/translat...

I suspect there might be more missing in #3014336: Handle the project:module format for dependencies to extract translatable strings from config: the l10n_server part. for l10n_drupal_rest, which is our currently-active connector module.

I've ported this patch to Drupal 8 because we were running into this issue for Drupal 8 potx.

We don't use the l10n_server but run potx locally which seems to do the trick :D

I missed a $potx_callback that was introduced that should be $_potx_callback in the 8.x version :)

I apologise for not running coding standards test locally.

While using these changes locally we found that some of our translation strings went missing. This could be related to the issue that drummm stated in #16

The specific scenario were this occurs was a module of an installation profile that had a message template inside the config/install directory.

While debugging I found that the array search for the fully qualified module name was incorrect because the path was used as search value but it's stored as a nested array of metadata.

The resulting code $module_qualified_name = array_search(['path' => $module_path], $_potx_found_modules, TRUE); should also be changed in the 7.x patch for anyone using this code.

I have a much simpler stopgap patch at #3042842: Profile dependencies and composer style dependencies are not found in config parsing that I am pushing out to potx now, which I independently arrived while working over the weekend with @shaal. That does not require localize.drupal.org changes. I need to understand why storing and managing the whole qualified name is helpful for potx/l10n_server to jump this big.

Retitling since #3042842: Profile dependencies and composer style dependencies are not found in config parsing resolved the immediate problem I think (?)

I destroyed the basic-localize dev site so we don’t have to consider thinking about keeping it up to date for security/etc updates. Let me know if a fresh dev site is needed for this.