Improve unit test coverage for ModuleHandler

Some people believe that separate functionalities should be covered by separate test methods.
Some people (and books, blog posts etc) even argue to only have one assert per test method.

In this MR I add stuff into the same method where it is practical.

Tradeoffs:
- Multiple asserts means you only see the first failure, later failures are unreachable. -> More iterations to fix the test.
- Multiple scenarios combined makes it harder to understand failure reports. It also makes it harder to understand what exactly we are testing and why.
- More separate test methods means slower test. This is generally ok for unit tests, though.
- More methods can mean more code and more effort to write them..
- There can be a risk of overcoverage in specific areas, which leads to redundant failure reports.

In this PR I want high coverage at low cost (effort and slowness)

First round of review could be nice to see if the direction is good.
And maybe others have more ideas what we need to cover.

There are many permutations of:
- What's in the cache
- Which files are already included at time of discovery.
- Different things happening in hook_module_implements_alter(): Removal or adding of implementations, changing the "group" of an implementation, changing the order.
- Hooks being sent in combination to ->alter().

Ticket has seemed to stale. I like the idea but may be above my head. I'm placing in committer bucket to get eyes on.

I'm triaging RTBC issues → . I read the IS and the comments. Comment #5 clearly asks for a first round of review and there is no evidence of such a review. I am setting back to Needs Review and tagging "Needs architectural review'.

I do understand how challenging it can be to get a review on an issue where there are few people with expertise, having experienced that in migration. However, the RTBC queue is for issues that are complete and all Core Gates are passed. One can argue that having an issue set RTBC is actually reducing the number of potential eyes on it.

Both myself and catch suggest continuing to ask in #contribute for reviews and perhaps asking those who can review to have a look. I expect we just have to wait until someone has the time available.

This is a big MR and complicated to review. Just some vague impressions for now :)

At the risk of starting a round of bikeshedding, I wonder if it might be better to split it into several issues, as I can see that each commit on the branch is testing something fairly different. Unless there's a lot of overlap in the fixture code?

Also, commit "Use constants for path to test modules." seems like a good idea but is adding noise.

> $expected_alter_combined_2

Variables with a 2 is a naming smell.

Overall this could do with a lot more explanation of what it's doing -- why the 3 .inc files, for instance? The @file block should say what is special about each one. I don't really understand the .inc files in general -- is the idea that they will get picked up by the module handler without needing to enable a module?

lets try that. Seems this issue has kinda stalled hard so maybe breaking up with help momentum.

I don't really understand the .inc files in general -- is the idea that they will get picked up by the module handler without needing to enable a module?

The purpose is to easily enable specific hook implementations through the fixtures in providerTestHookOrder(), without adding more and more complete module directories.

The goal is to cover niche scenarios where behavior could change if we try to refactor the system.
E.g. a typical fragile scenario is when calling ->alter() with more than one hook name, while some of these hook names are altered with hook_module_implements_alter().

It can be argued that coverage of a high range of combinations is paid for with a lack of clarity.
So yes, perhaps I should split this up and also make it more clear.