Add drush 9 generator support for bs_base

Initial patch. What was done:

1. Converted to Commands subclass
2. Removed deprecated code: drush_log, drush_print and drush_user_abort

The last command needs a bit more testing, didn't do any.

Addding the composer bit that was missing.

> We can not add support for bs_base generator for Drush 9+ versions in bs_base because themes are not supported.

Why not?

radix for example seems to have drush9 integration: https://git.drupalcode.org/project/radix

That said, if we make the code here re-usable then we could have an actual service with the logic and reuse it for drush 8 and 9 and *that* would actually be something only a module can do.

1. +++ b/composer.json
   @@ -10,5 +10,12 @@
   +        "drush.services.yml": "^9"
   

   seems like it is recommended to do ^9 || ^10 now.

2. +++ b/drush.services.yml
   @@ -0,0 +1,5 @@
   +  .commands:
   

   that should be bs_lib.commands?

3. +++ b/src/Commands/BsLibCommands.php
   @@ -0,0 +1,1719 @@
   +    // Child theme should not exist.
   +    if (!empty($child_path = $this->drupalGetThemePath($child_machine_name))) {
   +      $this->logger()->error("Child theme already exist on $child_path file system.");
   +      return;
   +    }
   

   From looking at some examples, it's also possible to throw an exception here, but not quite sure how that will look/work.

4. +++ b/src/Commands/BsLibCommands.php
   @@ -0,0 +1,1719 @@
   +    // Copy files from parent and change/apply text changes to labels.
   +    $this->copyThemeFiles($options);
   +
   +    // Replace text in copied files.
   +    $this->reconfigureThemeFiles($options);
   +
   +    // Generate some files from the scratch.
   +    $this->generateFile('theme-options.yml', $options);
   +    $this->generateFile("config/schema/{$child_machine_name}.schema.yml", $options);
   +    $this->generateFile('gulp-options.yml', $options);
   +    $this->generateFile($child_machine_name . '.info.yml', $options);
   +    $this->generateFile($child_machine_name . '.libraries.yml', $options);
   +    $this->generateFile('README.md', $options);
   +
   

   Yeah, this is duplicating a lot of code, so it would be nice if we could make it re-usable in a separate service, which themes can't provide. we could just load bs_base.drush.inc ourself and call the functions from that? we can still move them in here once we drop drush 8 support.

> 4.

Or we could have a service with commands logic too and then call those from both sides? Like described here:

https://nuvole.org/blog/2017/oct/13/how-maintain-drush-commands-drush-8-...

We could, but changing the existing could would likely conflict quite a bit with other things, there were already several changes to the code in bs_base since you started with this I think. I'd prefer a minimal approach for now I think, that changes as little as possible for existing code.

Addressing comments. I removed the code from all private methods and replaced with function calls. Or did we want to call the old functions from the command methods directly? I thought having this wrapper would make the move a bit easier later.

Also, some of the utility functions from bs_base use legacy methods like drush_print and drush_log. We will then change that when moving stuff here.

Also changing patch name,... seems like I used the nid from the bs_base issue.

Adding stuff from #3099329: Improve generator theme-options.yml content generation.

We were able to run commands without db before, adapting so we can do the same now:
- removed bs_lib module validation
- added correct bootstrap level info

Seems like we need to have themeRunUpdateHooks() in here, because the old function calls drush_confirm() which doesn't exist in d9 any more resulting in a fatal.

Addressing xposted review from here: https://www.drupal.org/project/bs_base/issues/3099329#comment-13423917

We can use $this->output()->writeln() instead, but we don't get the nice [foo] thingies there. In this patch I am faking them. Not sure if this makes sense, will remove if needed.

Yeah, faking it feels silly. Removed.

On the other hand, we have quite a log $this->output()->writeln( in the patch. This is not a "hacky" solution. From drush documentation using logger is preffered, but writeln is also possible if the output needs to be seen regardless of verbosity level.

We can still go the logger()->notice way though, if you think this suits better our needs.