AI support for contributors

[mk-mxp]

I am not sure, if we should add these. If we decide not to help contributors with using AI for contributions, I'm OK with that.

A main instructions file for the track's day-to-day work, and one for the contribution tooling. It saves a few tokens for the future.

And a minor fix for the PHP version range documented in README, nothing functional.

[homersimpsons]

While I personally find a lot of issues with LLM outputs quality (and their societal / environmental impacts). I'm not completely against introducing this. BUT:

1. I would prefer AGENTS.md (over CLAUDE.md) to avoid favouring (in terms of visibility) any AI provider. I know that @iHiD uses Claude though.
2. I would prefer we use no files if the informations are relevant for humans too. In which case we should seek concise writing and use classical README.md / CONTRIBUTING.md files
3. Similarly I would not gitignore the local LLM files, in my opinion the developers should ignore them globally instead. Though if we face a lot of good quality merge requests with local files included I will reconsider adding it.

[mk-mxp]

I'm not a fan of LLMs, too. I currently learn to use them (as we all have to), and a project without agent supporting files burns a lot more tokens (energy) than a project with them. Contributors use them anyways already, so let's save some tokens here.

To 1: I know, that Claude does not read AGENTS.md on purpose. That's a shame, but they are current market leaders (people urged to use Copilot for free on GitHub is no market share). I do not have another coding agent at hand to test support (cursor et al.). So, I can only reliably provide Claude information and supporting files.

To 2: Agent files are auto-generated and maintained by the agents. They read the README and code, and write their prose to safe tokens for the future. I do not intend to remove / reduce human first information anywhere.

To 3: gitignoring local agent files is common practice like .env.local.* already are. Especially with the many CDEs (like GitHub codespaces) global settings are unreliable. They also may contain security information (like tokens, keys for MCPs), as they are personal files.