Modify setup.sh to allow updating

@mczwier: After looking at the new `setup.sh`, I realized that if any of the former submodules were updated, that a novice user wouldn't have an easy path to updating the code. I changed things around so that if the directory containing the package doesn't exist, it's cloned, but otherwise the script does a pull to get any new changesets, and then updates to the revision specified by the script.  This assumes that the changeset that we want lives in `master` and it's going to be merged into `master`, which is currently true but may not always be. I think this should be pretty safe, as I'm assuming the average user won't ever modify the code so uncommitted changes and merge conflicts won't happen. Developers should have a handle on the structure of the code and git that they'll know the correct path to take when making modifications. 

Now a user should be able to just run `setup.sh` to get current with the subrepos. A `git pull` (or `git fetch/git merge`) can be done to get the main repo at the newest revision as before.

There may be a cleaner way of doing this. 

Anyways, I thought I would kick off discussing code decisions in Github using the first PR for the repo. I think in general though, we should get in the habit of not always pushing directly to `master` so that some code review can take place.