Improve MODULE_NAME calculation

I was making a comment, but decided to update the issue description with the changes that I suggest we do along the way and possible approach.

Thanks for the enhancement. Just a couple of thoughts:

• Not sure if MODULE_NAME is the appropriate name. It's more a PROJECT_NAME as it can be a module or theme or profile, or other things like recipes in the future.
• If a module has sub-modules, there is always more than one. This needs more thought on how to handle that. What's for sure that the requirements of jobs using that information will be different. If a job wants to enable those modules, i.e. the main module and all sub-modules, then a space separated list of all the (sub-)module names is required.
• One could argue that this method should just provide the name of the main module, but then there is that case where a Drupal module has no main module but a few sub-modules.

Agree.
* As MODULE_NAME is not documented and it's only used internally in one (soon to be two) job, we can totally change it to _PROJECT_NAME. As then _PROJECT_TYPE.
* Yeah. So far we haven't had a situation where we need to enable all the modules or a list of modules. I'd say let's wait until that need is created.
* Yup, that's what I said in the description about "the best guess". We can make the guess and show it in the job output. I think the best guess is usually the shortest name (ie: https://git.drupalcode.org/project/drupalorg - on the D7 branch)

We should still allow the option for a module maintainer to define _PROJECT_NAME and then only do the calculations if this is empty (default value). This way, we can easily fix edge cases where the above is not enough.