Update contributor documentation

Summary:
It's fairly common for people to show up and be interested in finding easy stuff to work on. This stuff basically doesn't exist and probably never will: it doesn't make much sense to deliberately leave easy bugs broken just because someone might show up and want to fix a couple of easy bugs.

Almost all of the work that's valuable to us requires a depth or bredth of context which can't be acquired in a few hours here and there, and probably always will. I think it also always should, in that as long as we continue refactoring and clearing technical debt aggressively and having solid static analysis support tools, we should never have a large backlog of human-intelligence codebase tasks. The closest we've ever come were probably pht() and phutil_tag(), which both have a lot of subtleties and we mostly automated phutil_tag() anyway. These tasks are also incredibly boring to write and review.

So, accept this as a reality and realign the contributor documentation to try to deal with this case:

• Set expectations about starter tasks not existing and throwing a couple of hours at the project writing code being a hard path.
• Suggest non-code contributions which anyone can do.
• Segue into code contributions with context and suggestions.

Test Plan: Generated and read documentation.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D8872