Pull request quality gates

[altavir]

There is already a bunch of nice features from KMath contributors. But since the code is usually sophisticated, some community design process needs to be enforced in order to make them play together. So here are some rules.

1. Any contribution with new classes/features must have test coverage of algorithmic part (not necessary 100% code coverage).
2. Any feature contribution must include a set of examples (goes into examples project), short feature description (goes into readme/feature section of appropriate module build file) and a design document (goes into docs directory). The design document is made to explain the design decisions made for the specific features (look at how KEEP works). Designing mathematics library is hard and we want all decisions to be consistent. The discussion in Kotlin Slack is welcome.
3. Any changes made to stable maturity modules must be ABI compatible between major versions and development maturity means ABI compatibility between minor versions. If your change is breaking it should be moved to a separate module or to the next release branch.

[CommanderTvis]

Completely agree with that documentation for all new features is mandatory; however, writing design documents seems to be a bit bureaucratic for research library.

[altavir]

I am not talking about "good" documentation, but at least some considerations are required. It is very hard to devise those considerations from PR. And nobody will do it after it is merged.