Add three more dos/donts to CONTRIBUTING.md

I've seen a couple PRs targeting the wrong branch. Many projects have a
workflow where PRs should hit `develop` or `release` or something, but
Metasploit-Framework wants PRs targeted against `master`.

Also, warn against fixing too much in one PR since those kinds of PRs
are a) harder to validate and b) might be all wrong anyway. We don't
want people committing a bunch of work when the fundamental approach
isn't going to fly.

Author: Tod Beardsley

CONTRIBUTING.md

@@ -23,6 +23,7 @@ and Metasploit's [Common Coding Mistakes](https://github.com/rapid7/metasploit-f
 
 ### Pull Requests
 
+* *Do* target your pull request to the **master branch**. Not staging, not develop, not release.
 * **Do** specify a descriptive title to make searching for your pull request easier.
 * **Do** include [console output](https://help.github.com/articles/github-flavored-markdown#fenced-code-blocks), especially for witnessable effects in `msfconsole`.
 * **Do** list [verification steps](https://help.github.com/articles/writing-on-github#task-lists) so your code is testable.
@@ -34,14 +35,15 @@ Pull requests [#2940](https://github.com/rapid7/metasploit-framework/pull/2940)
 #### New Modules
 
 * **Do** run `tools/msftidy.rb` against your module and fix any errors or warnings that come up. Even better would be to set up `msftidy.rb` as a [pre-commit hook](https://github.com/rapid7/metasploit-framework/blob/master/tools/dev/pre-commit-hook.rb).
-* **Do** use the [API](https://dev.metasploit.com/documents/api/). Wheel improvements are welcome; wheel reinventions, not so much.
+* **Do** use the [many module mixin APIs](https://dev.metasploit.com/documents/api/). Wheel improvements are welcome; wheel reinventions, not so much.
 * **Don't** include more than one module per pull request.
 
 #### Library Code
 
 * **Do** write [RSpec](http://rspec.info/) tests - even the smallest change in library land can thoroughly screw things up.
 * **Do** follow [Better Specs](http://betterspecs.org/) - it's like the style guide for specs.
 * **Do** write [YARD](http://yardoc.org/) documentation - this makes it easier for people to use your code.
+* *Don't* fix a lot of things in one pull request. Small fixes are easier to validate.
 
 #### Bug Fixes