Add GitHub status formatter

[mknapik]

Solves #121.

The formatter creates one commit status per runner with information about issue counts.
Issues in status description are ordered by severity.

By default all Pronto Messages with level :warning or higher are considered a failed state for GitHub status (red status).
GithubStatusFormatter allows to override this behaviour by accepting :level_mapping option in the initializer (which is not supported when running the formatter directly with command line, e.g. pronto run -f github_pr_status).
There is no README info yet but I'll provide it once we agree on the interface and the way this formatter should work.

The result of running Pronto with the new formatter:

@mmozuras Please let me know whether the PR adheres to the project conventions.
I got some RuboCop line to long warnings in specs, should I fix those?
Also I'm going to squash refactoring commits before merging.

[mmozuras]

Not sure if it's worth having a way to override it. Let's leave it off for now 😄

[mknapik]

The reason for implementing this was that Reek was returning only warnings even though stuff like Doesn't depend on instance state (maybe move it to another class?) (UtilityFunction) sound pretty subjective to me. Now when I think about it, it'd probably be better to address the issue at mmozuras/pronto-reek than here.

I'll get rid of opts parameter for now.

[mmozuras]

@mknapik amazing, thank you, honestly 👏 😄

Just address a couple of comments, add info to README and CHANGELOG and it's gonna get merged! 😄

[mknapik]

@mmozuras Apart from adhering to your remarks I've also did some refactoring.
Additionally I renamed formatter cli name from github_pr_status to github_status.
Let me know what do you think.
I haven't squashed everything yet so you can review the changes easily.

[mmozuras]

I think that it's worth showing that multiple formatters can be used here too.

[mknapik]

Ok, I'll add one more example.
Although I believe using multiple formatters is not documented anywhere else.

[mmozuras]

@mknapik looks good, just address my one last comment 😄

[aergonaut]

@mknapik @mmozuras would it be too much to ask to have the status contexts formatted more like how other services format them? i.e. instead of "Pronto::Rubocop", something like "pronto/rubocop" or "lint/pronto/rubocop" to be more similar to how Travis CI uses "continuous-integration/travis-ci/pr"

[mknapik]

@aergonaut Actually I had no idea what was the convention.
The docs use continuous-integration/jenkins and security/brakeman as examples.
I guess I can change it to pronto/$runner.

[mknapik]

@mmozuras @aergonaut Regarding context names:
Do you think a simple function like runner.class.downcase.gsub('::', '/') is enough or should I implement something like ActiveSupport::Inflector#underscore?

The difference:

Pronto Runner	downcase	underscore
Pronto::Brakeman	pronto/brakeman	pronto/brakeman
Pronto::RailsBestPractices	pronto/railsbestpractices	pronto/rails_best_practices

[aergonaut]

@mknapik looks good to me 😄

[mmozuras]

@mknapik looks good, amazing contribution 👍 🙇

[mknapik]

@mmozuras Thanks!
The gem is well written and contributing was a pleasure!

[kevinjalbert]

This is awesome. Was trying to make it work using version 0.6.0, then realized that this isn't released yet 😉 .

I look forward to using it in the next version bump.