Introduce :overrides option

[vemv]

Brief

Implements #134 (comment)

Starting from this PR, :overrides becomes the primary API for customizing things: as a consumer, one should:

• Use one of: git-status-formatter, branch-formatter, project-formatter
• Pass :overrides to those if wanting to tweak something.

...and should not:

• Use core/format! directly
• Use the "factory" stuff introduced in this PR

TODO

• At this point, git-status-formatter, branch-formatter, project-formatter all deserve some test coverage.
• Explore how much can we DRY git-status-formatter, branch-formatter, project-formatter
  • A nice 'overrides' implementation would allow absolute DRY.
  • Might be less prioritary for now
• Create impl sub-nses for git-status-formatter, branch-formatter, project-formatter
  • The intended API is format-and-lint! / lint!
  • Things like speced/defn default-formatters are certainly not public
• Review doc (README)
• Review examples (test-resources)

QA plan

• git-status-formatter, branch-formatter, project-formatter all keep working
• The examples work as advertised, customizing things as its code shows

Author checklist

• I have QAed the functionality
• The PR has a reasonably reviewable size and a meaningful commit history
• I have run the branch formatter and observed no new/significative warnings
• The build passes
• I have self-reviewed the PR prior to assignment
• Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
  • Correctness
  • Robustness (red paths, failure handling etc)
  • Modular design
  • Test coverage
  • Spec coverage
  • Documentation
  • Security
  • Performance
  • Breaking API changes
  • Cross-compatibility (Clojure/ClojureScript)

Reviewer checklist

• I have checked out this branch and reviewed it locally, running it
• I have QAed the functionality
• I have reviewed the PR
• Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
  • Correctness
  • Robustness (red paths, failure handling etc)
  • Modular design
  • Test coverage
  • Spec coverage
  • Documentation
  • Security
  • Performance
  • Breaking API changes
  • Cross-compatibility (Clojure/ClojureScript)

[vemv]

@thumbnail : Progressed quite a bit. Although the branch isn't pretty, the extended specs, examples, protocols, tests etc should make it quite clear the overall intended API.

You might want to take over the branch, as I see it it's 90% there.

[vemv]

(Important to address this XXX)

[vemv]

Closing so that I'll push a rebased version.