Scope composer tools with the bin plugin

[ChristophWurst]

This puts our current dev tools into isolation, so they and their dependencies won't interfere with vendored production dependencies.

Ref https://github.com/bamarni/composer-bin-plugin for those new to this plugin

Summary

• Dev tools are no longer part of the production autoloader -> fewer conflicts
• Dependencies are installed as before
• Scripts are executed as before

Changes for developers: ✨none✨

The same trick has been used in Mail for months. It helped us get rid of tools that pulled in incompatible versions of Symfony.

[ChristophWurst]

Neat side effect: when you composer i now the list of untracked files is really small. It was quite big before

$ git status
On branch enhancement/composer-bin-plugin-for-tools
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   lib/composer/composer/autoload_classmap.php
        modified:   lib/composer/composer/autoload_psr4.php
        modified:   lib/composer/composer/autoload_static.php
        modified:   lib/composer/composer/installed.json
        modified:   lib/composer/composer/installed.php

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        lib/composer/bamarni/

no changes added to commit (use "git add" and/or "git commit -a")

[juliusknorr]

lib/composer/bamarni/ could probably be added to the gitignore file.

[ChristophWurst]

lib/composer/bamarni/ could probably be added to the gitignore file.

Yes but no :P

What I don't like about that is that you get different autoloaders for composer i vs composer i --no-dev. When that lib is in the .gitignore then you could have the lib missing but the autoloader still points to it.

This might be a purely theoretical problem.

The other solution I'm fine with would be to just vendor the lib together with #28509.