Drake: Add more best practices to developers.rst

[jwnimmer-tri]

Many Drake developers have best practices that are not documented for others to use:

• Use ccache (moved to #3521).
• Use CMAKE_BUILD_TYPE=Debug.
• Compile within drake/drake instead of at the superbuild level.
• git clean -fdx (aka "nuke from orbit) instead of make clean (moved to #4551).
• [x] Before you change 'make options', nuke from orbit. The build system is unsound (see #1860).
• [x] Run pimpmychangelog after updating the change log. (Well, random tool requirements suck, so don't actually do that. Just be sure to fix the links in your markdown file by hand.)
• When describing a PR that will impact an issue, use the magic words listed here.
• [x] Before changing the code, first run clang-format. Then commit and issue a PR for just the changes made by clang-format, which should all be non-functional. You can then proceed to make and commit your functional changes and issue a second pull request. Hopefully, prior to completing your functional changes, your first PR is merged, preventing you from having a massive number of conflicts to deal with. This is better than combining both the clang-format changes and your changes into a single PR since it will allow the reviewer to more easily determine and review your functional changes.
• [x] Document the use of "@drake-jenkins-bot retest this please" to trigger another round of Jenkins CI tests. https://github.com/RobotLocomotion/drake/issues/2000
• [x] Document the use of ctest to run unit tests, similar to that in: https://github.com/RobotLocomotion/director/blob/master/docs/sphinx/developer_guide/running_tests.rst
• [x] Specifically explain ctest -VV -R testregexp use case.

There are probably more that I haven't heard about yet.

We should document these in drake/doc/developers.rst so that everyone can benefit.

[amcastro-tri]

This is great @jwnimmer-tri!
I would add that when running clang-format/cpplint for the first time on a given file(s) the format changes from clang-format/cpplint should be in a separate PR so that the original PR is clean from a large number of white-space corrections.

[jwnimmer-tri]

I agree. It looks like someone already editing the checklist to reflect this (yay).

[amcastro-tri]

Nice @liangfok!

[jwnimmer-tri]

Everything in this list either (1) is done or (2) has been moved to a specific issue or (3) only applies when using CMake. I will close this. Folks should feel free to contribute helpful PRs or file new issues as appropriate, but I'm not sure the meta-issue is helping anything here.