README: remove wrong claim about backwards compatibility

[Wertzui123]

I have requested this change several times in the discord already. The response was always something like "those changes are handled automatically" or "V is not mature enough to not break things yet" - and while I agree with the latter, the statement that v fmt handles breaking changes is simply wrong (partially because it doesn't make any sense to automate that process in some situations).

One recent example of this is 11337e7; this commit forbids variables called thread to be declared and is not handled by v fmt.

Another case from half a year ago is 404a9aa.

Here's one more: 46f32fc; this only introduced a warning, but since warnings are errors in -prod mode, it also broke my code.

To make it clear, I very much think that those changes make sense and that V should break things from time to time, but I just don't like the claim.

Let's discuss this topic in this PR as I think we might want to introduce some kind of BC compatibility promise, but the current one is unrealistic and simply wrong.

[JalonSolov]

The main problem with the stability section is that it should state "as of the 1.0 release". V doesn't guarantee anything until then, though it tries to remain as compatible as possible.

[cpajonk]

👍 breaking changes are a normal part and more than understandable in early development.
It would increase trust if the claim is adapted to better reflect the actual situation.

[medvednikov]

Thanks.

I've made the wording much better. It now reflects the actual situation:

https://github.com/vlang/v#stability-future-changes-post-10-freeze

[Wertzui123]

Thank you!