Allow adding to a released version conflicts

When a dependency package / PHP extension update is released and contains a breaking change, the package maintainer that depends on that package gets a lot of support requests because of the problem.

The issue can be resolved by adapting the new stuff or introducing a conflict, which can only be added in a new version.

So my suggestion here is to allow adding afterwards conflicts to already released versions, in that way package maintainers can configure this for wide range of versions and don't get a lot of support.

There are user-land approaches to handle this, like `contao/conflicts`: https://github.com/contao/conflicts
which works but cannot be used together with tags, so you cannot set different conflicts for different versions.

Real-world issues that could be solved easier:
- https://github.com/phpredis/phpredis/issues/2562

Such things often happen: https://github.com/contao/conflicts/commits/main/, which would make the life of package maintainers easier.

The change to Packagist itself would be straightforward. It would let the user manage the conflicts and merge the additional conflict data with the data in composer.json. So, an actual code change would be required, as only the metadata in Packagist matters.

What do you think about such a change in Packagist?

The issue does not name specific files, tests, or entry points. Start by tracing how Packagist stores and serves package metadata, then determine how post-release conflict data would be managed and merged with composer.json metadata. Done means the behavior and its impact on versioned package metadata are clearly specified and covered by tests.

Written by the indexing model from the issue text.