Document the development process

[kgriffs]

Inspiration:

• https://cryptography.io/en/latest/development/
• https://smartbear.com/SmartBear/media/pdfs/11_Best_Practices_for_Peer_Code_Review.pdf
• https://wiki.openstack.org/wiki/Zaqar/Reviewer_guide

Notes:

• Before merging, squash commits in a PR down to one per logical change.
• Review criteria
• Number of LGTMs required, etc.
• Requirements around docs, testing (100% coverage doesn't necessarily mean you've tested a good range of inputs), security, performance, commit message style, etc.
• Standardize line wrapping rules for function definitions and calls with long param lists irrelevant with black now

[vytas7]

Also consider mentioning this: https://github.com/falconry/falcon/issues/1625#issuecomment-569364069

I think we will have to include comments or alternative sample code when we do a breaking change, that shows both the "stable release" version and the latest hotness.