Add contributor guidelines on deprecation lifecycle: warning, migration, removal

[lochhh]

There is currently no documented guidance on how contributors should handle breaking changes, such as API removals, behaviour modifications, or incompatible defaults.

It would be helpful to define a contributor-facing policy that includes minimally:

• When and how to use warnings, e.g. FutureWarning, DeprecationWarning
• Minimum deprecation timeline before removal (e.g. N+2 or 3 minor? releases)

Additionally, consider

• Documentation expectations: changelog entries, migration notes, etc.

[niksirbi]

Thanks for opening the issue!
I'm linking this here as an example of how we've handled that in the past. This doesn't necessarily need to form the core of the guidance.

It would be also useful to examine how other established scientific Python projects do this.