WIP Update optparse-applicative to master and use prettyprinter library instead

[newhoggy]

[RyanGlScott]

Thanks for the PR, @newhoggy. I'm a bit unclear on what the purpose of this PR is. Is the goal to replace the use of ansi-wl-pprint with prettyprinter? If so, then optparse-applicative (a dependency of criterion) will need to be patched first, as its footerDoc function (which criterion uses) makes use of ansi-wl-pprint's Doc type rather that prettyprinter's Doc.

The PR title mentions something about optparse-applicative master, but as far as I can tell, the master branch of optparse-applicative still uses ansi-wl-pprint, and the PR itself doesn't change the version of optparse-applicative being used. As things stand, I'm uncertain how this is meant to work.

[Bodigrim]

@RyanGlScott I think this is a counterpart of https://github.com/pcapriotti/optparse-applicative/pull/428

[RyanGlScott]

optparse-applicative recently made two releases that support prettyprinter:

• optparse-applicative-0.17.1.0 supports ansi-wl-pprint-1.*, which re-exports prettyprinter functionality.
• optparse-applicative-0.18.0.0 drops its ansi-wl-pprint dependency and instead depends on prettyprinter directly.

I think we should follow suit in criterion. I'll prepare a series of two PRs (based on the changes in #241 and #242) such that we will have:

• A criterion release that supports optparse-applicative-0.18.*, in addition to previous optparse-applicative releases that use ansi-wl-pprint.
• A criterion release that requires optparse-applicative-0.18.* or later and explicitly depends on prettyprinter.

[RyanGlScott]

See #275 (which widens optparse-applicative support) and #276 (which requires optparse-applicative-0.18.* as the minimum).

[RyanGlScott]

I've released criterion-1.6.1.0 and criterion-1.6.2.0 to Hackage, which include the changes from #275 and #276, respectively. As such, this PR has been superseded, so I'll close this.