Proposed change to GitHub workflow #461

To support the broader pool of developers, and per a suggestion by @bstabler, I am proposing this modest change in our GitHub workflow. In short, the changes codifies the develop branch as a place to stage features that are ready for the next release, and not a place where new features are built and tested.

• The master branch contains the latest release version of the ActivitySim resources
• The develop branch contains new features or revisions planned for the next release.
  Generally, developers should not work directly in the develop branch.
• Work to implement new features or other revisions is done in an issue/feature branch
  (or a fork) and developers can open a pull request (PR) to merge their work into develop.
• The test system automatically runs the tests on PR's. PR's do not necessarily need to pass
  all tests to be merged into develop, but any failures should be cause by known existing
  problems -- PR's should strive to not break anything beyond what was broken previously.
• Upon review and agreement by a consortium member or committer other than the author,
  and barring any objection raised by a consortium member, PR's can be merged into the
  develop branch.
• If tests pass for the develop branch, new features are suitably documented, and on approval
  of a lazy majority of the PMC, a repository administrator can approve a manual pull request to merge
  develop into master, and otherwise make a product release.