Write a backwards-compatibility policy

What is the problem or limitation you are having?

Toga's release notes contain a backwards incompatibility section; however, that doesn't provide any guarantees about what is and isn't considered to be part of the public API, and what level of compatibility users can expect.

#2302 identified a minor backwards compatibility issue that stemmed from this ambiguity.

Describe the solution you'd like

A formal backwards compatibility policy, describing what is and what isn't part of the public API surface.

It should cover how stable and beta APIs can be identified, and how Toga will address issues as they arise. It should also highlight what Toga's version numbers "mean" - specifically:

• We're pre v1.0 so there will be sharp edges
• The closer we get to v1.0, the less sharp edges there should be
• Once we're "stable", we'll jump to calendar versioning.

As part of this change, we may also want to audit the APIs to enforce the use of keyword arguments in more locations. The issue in #2302 arose because an argument that should almost always be used as a positional argument had a change in name. Most widget arguments should be keyword arguments, rather than relying on position (with some possible exceptions like the label on Buttons and Labels); explicitly calling out that the name of positional arguments isn't guaranteed would make renaming positional argument a lot easier.

Describe alternatives you've considered

There isn't really an alternative - this is something we need to write.

Additional context

No response

Start by reviewing Toga's release notes and issue #2302 to understand the compatibility ambiguity. Write a policy covering the public API, stable and beta APIs, issue handling, and the meaning of pre-1.0 and future calendar versioning; done means these expectations are documented clearly, with any API audit treated as a separate consideration.