Use ReaderT to carry the OIDC settings

[ixmatus]

The primary reason for this change is to pave the way for user-defined HTTP manager / request settings that need to be carried with the OIDC settings (but do not really belong in the data type itself). ReaderT is more natural anyway for carrying the OIDC settings around to all the different functions that need it.

There's some very minor refactoring activity (e.g using local let bindings instead of where bindings), I tried to keep it specific to the addition of the ReaderT type though.

I know this is an API lift, so it likely requires a new minor version bump if this change is accepted.

[ixmatus]

The latest build errors look like issues with the builder themselves. Is there anyway to retry the builds?

[ixmatus]

CC: @krdlab.

[ixmatus]

NB this PR may be moot, I've realized that the important functions which need a modified Manager can actually modify it. However it's probably worth determining whether we still want to use a ReaderT for the commonly shared OIDC value. I personally think it's still nice to use.

We could improve the interface a bit more by using a custom Monad that just wraps ReaderT though so it reads more naturally, e.g runTokenFlow or runOIDC or something.