In practice, when @dependabot sends a patch, this workflow will be triggered once the `build`
workflow is completed successfully, and applicable patches will be automatically merged.
TL;DR: polyfills are to be installed by downstream consumers, and not provided by libraries
In order to support PHP 7.2, 7.3 and 7.4, the `symfony/polyfill-php80` library
was dragged in. Symfony now has a long track record of bad stability ranges
(see https://github.com/symfony/polyfill-php80/blob/f4386d7f6f66346254ed4e6bfa4354d2d16b83f8/composer.json#L22-L24),
so it is best to get rid of it, and instead declare API compatibility with a stable API
version (in this case PHP 8.0).
In addition to that, to avoid introducing an explicit `ext-ctype` requirement, `symfony/polyfill-ctype`
was dragged in too, perhaps in an attempt to retain more popularity.
Same as above: symfony has a bad track record of SemVer compliance, so it should
not be introduced until strictly necessary. `ext-ctype` is generally available to most target
installation systems, and downstream consumers are still free to pull out their foot-gun by
doing a `composer require symfony/polyfill-ctype` on their own.
This mean that systems having `ext-ctype` installed will get an installation as expected: otherwise,
any system that requires `ramsey/uuid` automatically becomes a system capable of providing `ext-ctype`
API, which is just not true (before this change).