experimental change management proposal

[Carwyn Pelley]

Following from https://github.com/SciTools/iris/pull/2781 I want to see whether there is interest with other devs on this:

Currently the change management whitepaper allows experimental modules to be removed without notice

I'm proposing here the following:

- Changes to experimental should depend on the extent to which the API has changed.
  - If the behaviour has changed or the arguments have changed then this can be done without notice.
  - If a public function/class is to be removed entirely, these should instead be deprecated.  I think this is especially important where code has not "graduated to full status" in the iris code base (as described here).
- I think the longevity of the modules and functions in experimental should carry weight as they almost certainly do with users.
- Experimental content could be evaluated for leaving experimental within a certain timespan (and that message be communicated).  Without these timely evaluations, I don't think we can sell these as really experimental in any sense we would like them to be and can't expect to treat them as such.

I think it would be interesting to gauge with users of their perceived understanding of experimental modules was but let's hold fire on that for now.  It's important however, to consider what experimental modules mean to end users.

Cheers