hook_requirements($phase = 'install') does not work as expected for experimental modules

Here's a test and a fix.

@tim.plunkett thanks for the review.

InstallUninstallTest you are a fun one :)

Okay now for real. Just making the module hidden.

Wrong .info.yml file... omg.

Experimental modules are denoted via the package
Testing modules are also denoted via the package

I'd love to see an explicit experimental: true flag in info.yml, so that contrib can have experimental modules too.

Testing modules are usually identified by being in a /tests/.. path, I think that test is the only thing that does the package test, maybe we should change that? Testing modules used to be hidden before we added the logic about not parsing /tests/ for modules unless a certain flag is set. Which is obviously set while running tests.

\Drupal\Core\Extension\Discovery\RecursiveExtensionFilterIterator::acceptTests() is responsible for the experimental modules not being displayed. #18 looks good.

@xjm noticed a few things on review.

1. I'd love to see an explicit experimental: true flag in info.yml, so that contrib can have experimental modules too.

   I'm also totally in favor of this; we discussed it for somewhere. I noticed that there is already a "Chaos Tools Suite (Experimental)" package to try to accomplish the same thing we do for core, but of course it does not provide the requirements warning and confirmation that core does.I thought there was an existing issue for it but it does not seem to be listed on #2649768: [meta] No definition of "Experimental" & not nearly enough warning at least. So let's explore that in a followup. (Using the package name alone was the minimum hack we could do to get it working in the last months before 8.0.0 without any API change/addition).

2. Testing modules are usually identified by being in a /tests/.. path, I think that test is the only thing that does the package test, maybe we should change that? Testing modules used to be hidden before we added the logic about not parsing /tests/ for modules unless a certain flag is set. Which is obviously set while running tests.

   I also ran into this when adding the experimental module confirm form. At the time, I think I investigated why the test used the "Testing" package name instead of "test" in the path or another strategy . This dates back to #1871328: Modules in new Multilingual package are no longer tested by Module\EnableDisableTest. Before the issue that introduced that regression, there was only the core package and the testing package, and the testing profile and test module discovery had not been introduced yet.

   That said, though, when I was working on #2649768: [meta] No definition of "Experimental" & not nearly enough warning I did rely on on InstallUninstallTest to also provide test coverage for the experimental modules. So if we change InstallUninstallTest to skip them, we should also make sure that there is other coverage for the cases in that test.

   TLDR, also followup material.

3. +++ b/core/modules/system/src/Tests/Module/ExperimentalModuleTest.php
   @@ -120,6 +120,14 @@ public function testExperimentalConfirmForm() {
   +    \Drupal::state()->set('experimental_module_requirements_test_requirements', TRUE);
   +    $edit = [];
   +    $edit["modules[Core (Experimental)][experimental_module_requirements_test][enable]"] = TRUE;
   +    $this->drupalPostForm('admin/modules', $edit, 'Install');
   +    $this->assertUrl('admin/modules', [], 'If the module can not be installed we are not taken to the confirm form.');
   +    $this->assertText('The Experimental Test Requirements module can not be installed.');
   
   +++ b/core/modules/system/tests/modules/experimental_module_requirements_test/experimental_module_requirements_test.install
   @@ -0,0 +1,20 @@
   +  if (\Drupal::state()->get('experimental_module_requirements_test_requirements', FALSE)) {
   

   I asked @tim.plunkett why we are using this state check when we only explicitly test the TRUE case. This is because of the above bit where InstallUninstallTest skips the testing package, but experimental test modules can't be in the testing package because they are in the experimental package.

   I thought of asking for an inline comment in case someone else had the same question, but it's not worth it for a test module IMO. After all, if someone tries to remove this, InstallUninstallTest will explain itself by failing. ;)

4. I manually tested this patch both with an experimental module that failed requirements, with a "contrib" module that depended on said requirement-failing experimental module, and then both cases where the experimental module also met requirements. In each case, the patch worked as expected.

I committed this to 8.3.x, but we are in a commit freeze at the moment on 8.2.x, so leaving RTBC for backport tomorrow.

Thanks everyone!

Backported to 8.2.x. Thanks!