Merge pull request #1 from dbnicholson/master

Added ability to mirror bare repositories
Merge pull request #2 from dbnicholson/master

Wiki fetching + various fixes
Update README.md
Update README.md
Update README.md
Factor out get_color_str to be used from multiple classes
Factor out system_exec to be used from all classes

Since it no longer has access to the user's desired directory, we
basically always have to pass it in.
Store full args dictionary in RepoUpdater

Later when the repos are split out into their own classes, this will
make passing it the necessary configuration easier. This does mean that
we don't want to delete keys in the dictionary as it will affect ongoing
operation.
Add keys for new attributes in AttributeDict

When the dictionary key already exists in AttributeDict, setting it by
attribute reference works because __getattr__ returns a valid key. If
the key doesn't exist, then setting a new attribute will result in an
actual attribute being added to the AttributeDict. Defining __setattr__
to always set a dictionary key fixes this.
Rework code and wiki repos into their own classes

This helps pave the way to adding content from the GitHub project that's
not in git format. In that way, each content type can define how it
updates itself instead of piling more utility methods into RepoUpdater.
The WikiRepo tries to reuse the GitRepo methods as much as possible.

The ugliest part is probably in the get_json changes. First, we need to
tell it different object types to use rather than always AttributeDict.
Second, we need to pass through the configuration parameters to the
object, but our object hook doesn't allow for that. We could write a
separate JSON decoder, but this just hacks around it for now.
Ignore the has_wiki setting

The has_wiki repo attribute indicates whether the wiki is shown on the
website or not. It actually doesn't correspond to whether the wiki
exists or not, which makes sense since has_wiki can be true even if the
wiki is uninitialized.
Refactor repositories to better match GitHub repositories

When the wikis were added, it was treated as another repository from
GitHub. But once that thought is extended to issues, milestones, etc.,
it becomes clear that the idea of a repository would be better to match
how GitHub thinks of a repository: a project with different streams of
content including a code repo.

This change adds the top-level GitHubRepo class, which holds all the
JSON API data and then adds the content repositories. This also means
that the number of repositories again corresponds to the number of
GitHub repositories and not actual git repositories.
Split out API json reading and object construction

We'll reuse these when creating repos of the json data, so split them
out to toplevel functions. This requires that we always pass in the
configuration arguments, so the hack to run the configure method if the
config argument is set has been removed. Instead, we just run the method
directly when creating the GitHubRepos.

Also, the actual of fetching of the json has been split from the object
creation since later we'll just want the json data as is without
creating an object from it.
Don't print system_exec output when there is none

This just keeps an unneeded blank line from being output when the
process has no output on stdout.
Add JsonRepo class to handle general repo API content

Unlike the code and wiki that reside in git directories, things like
issues and milestones are just json returned by the API requests. In
these cases, we'll make a simple store that mirrors the API paths. Each
json delivery is saved to a file with the relative API path with .json
suffix.

This class is setup to allow each content type to easily subclass it
with a minimal amount of code. Basically, they'll just have to tell it
what URLs to download.
Add IssuesRepo class to gather repo issues

Uses the JsonRepo class to store data from the GitHub repo issues
API[1]. They toplevel issue, comments and events are stored.

The option --include-wikis has been renamed to --full-backup to save us
from an explosion of content selection options. Instead, the option is
code backup or code + wiki + issues + ... backup.

1. https://developer.github.com/v3/issues/
JsonRepo: Allow downloading arbitrary files

Some files such as patches don't need to take the '.json' alternate
suffix, so allow setting the suffix for the file. Rename read_json to
the more appropriate read_api_uri and remove some duplication in the
download paths.
Add PullsRepo to gather pull requests

Uses the GitHub Pull Requests API[1] to gather repo pull request data.
The toplevel pull request as well as a squashed patch, commit messages
and review comments are saved.

1. https://developer.github.com/v3/pulls/
Add the MilestonesRepo to gather project milestones

Fetches the json for each milestone in a project. While the url is
directly underneath the repo, this is actually part of the issues API
and will return an error if issues are not enabled for the repo.

1. https://developer.github.com/v3/issues/milestones/
Sanitize the content URL in JsonRepo

Instead of repeating this for all content types, pass the desired URL to
the JsonRepo initializer and let it do the sanitization. We'll assume
that everything past the first '{' is just a hint for further
enumeration.