Check that translation and the `ReaderT` really do work by changing
localisation of the STDOUT "help" output from `EN` to `FR`.

To actually test this, add a french translation of the `GitHubCommit`
plugin description. This string is successfully output by the "help"
plugin.

A test to try to get _something_ to compile. And it does!

Here we try to run a plugin with `runReaderT` and `runBot` to pass
`Options` to the plugin, using the "help" plugin as an example. It feeds
hard-coded `Options` to the plugin and outputs its response to STDOUT.

Also get an implementation of `initializePlugins` working that will
allow us to build a list of plugins with `Options` applied to the
reader.

This commit comments out the whole of IRC.hs in order to get the code to
compile. That file still has a bunch of `Bot` monad-related type errors.

To build the final plugin list, I think what we'll want to do is use
something like `initializePlugins` in Lib to apply all our plugins with
the `Options` and then feed that to `connectIRC`. In order to build the
"help" plugin, the plan is to re-apply the `Options` after `ask`ing for
them inside the `PluginAction` for "help" to all plugins, thus enabling
us to get a plugin list with the applied reader for proper localisation
of the help output.

Convert this function and `Plugins(performPlugin)` to use a
`Bot`-wrapped plugin.

Still having a lot of trouble with this, unable to get past
monad-related compilation errors. The plan is to leave this as-is for
now and attack the problem from a different place, looking at the `main`
function next, applying our plugins with `runBot`, and then passing
those monad-wrapped plugins to `connectIRC`. Once that's taken care of,
we'll see what we need to modify in this middle strata of the stack.

Previously we added the `Bot` monad to our signature, but we didn't have
a way to filter and match plugins wrapped in the `Bot` monad. This is
what we're doing here. It's the same work as before, but we need to
account for a wrapped `Plugin` type.

There's a lot of extra cruft code here from when I was trying things out
to get it working. The short story is that I do some binding and
sequencing dances to extract `Plugin`s so that we can actually match
against them.

I've seen recommendations against `fail`, which is why I tried to use
`mzero`, but it just seemed to be too complicated so went with `fail`,
which seems to make sense in context.

Since our plugins are now wrapped in the `Bot` monad, the plugin list's
type needs to change.

Also update `matchPlugin` to return a `Bot Plugin`.

The plugin list's type has changed from `[Plugin]` to `[Bot Plugin]`. In
order for our code here to work, we need to unwrap the `Bot` part so we
can get access to the `Plugin` again and do the same work.

Fortunately, using `sequence`, we can turn our `[Bot Plugin]` into a
`Bot [Plugin]`, which is then easily bound with `<-` and passed to our
old code to be handled like before. Yay!

Add our `Bot` monad to the rest of the plugins:

* Factorial
* GitRemoteSetOrigin
* Help

The only problem is with the Help plugin. Still trying to figure out how
to set up my list comprehension so that it works with the `Bot`-wrapped
`Plugin` list.

An old config object, from before I decided to go with the `Bot` type.
Committed here just to show some of the process. We'll be removing it
soon.

Oh my goodness, it works!!!!!!! I've been wrestling with this for the
past week and a half, and it finally works!

Here's the compiler error I was getting:

    sorbot/src/Plugin/GitHubCommit.hs:25:12: error:
        • Couldn't match type ‘Control.Monad.Trans.Reader.ReaderT r0 m1’
                         with ‘Bot’
          Expected type: Bot t0
            Actual type: Control.Monad.Trans.Reader.ReaderT r0 m1 t0
        • In a stmt of a 'do' block: cfg <- asks language
          In the expression:
            do { cfg <- asks language;
                 return
                   (defaultPlugin
                      {matchRegex = "^[0-9a-f]{40}$", perform = gitHubCommitAction,
                       command = "<git_sha>",
                       description = translate (lang cfg) GitHubCommitDescription}) }
          In an equation for ‘gitHubCommit’:
              gitHubCommit
                = do { cfg <- asks language;
                       return
                         (defaultPlugin
                            {matchRegex = "^[0-9a-f]{40}$", perform = gitHubCommitAction,
                             command = "<git_sha>",
                             description = translate (lang cfg) GitHubCommitDescription}) }

The problem ended up being that I was using the wrong `ask` & `asks`
functions. After a lot of searching online and reading articles and
things about how to set up `ReaderT` configuration, I finally started
looking at some code, from a "language:Haskell newtype app readert"
search on GitHub. Reading different code bits, I tried to compare with
what I had already, kept reading. Finally I noticed that the imports
were different, and I tried getting `ask` not from the transformer
library, and it worked!! OMG! So glad.

Since we're trying to get the language from an `Options` type in the
reader, we need to use the `language` helper instead of our custom
`lang` (which operates on `IO`).