rename Close to avoid name ambiguity, fixing Windows build

[robx]

Somehow, we import GHC.Event.Windows.ConsoleEvent.Close on Windows via Hasql.Pool.Prelude, which conflicts with Close.

• might be nicer to avoid that import, but I couldn't figure out where it even comes from precisely (and I wouldn't want to conditionally hide an import based on CPP...)
• should Windows be added to CI to verify this / prevent it in the future?

See this PostgREST CI failure: https://pipelines.actions.githubusercontent.com/serviceHosts/996fe3a3-010d-4e7c-a003-8e967bc4327c/_apis/pipelines/1/runs/2550/signedlogcontent/2?urlExpires=2022-08-30T06%3A30%3A28.3317426Z&urlSigningMethod=HMACV1&urlSignature=hCE13v%2Fp7jkakftXs%2FRp%2FY1EkmZVfgiucJpcj1kcobA%3D

2022-08-30T00:12:23.7448486Z hasql-pool                   > library\Hasql\Pool.hs:82:31: error:
2022-08-30T00:12:23.7613309Z hasql-pool                   >     Ambiguous occurrence `Close'
2022-08-30T00:12:23.7625695Z hasql-pool                   >     It could refer to
2022-08-30T00:12:23.7647920Z hasql-pool                   >        either `Hasql.Pool.Prelude.Close',
2022-08-30T00:12:23.7650835Z hasql-pool                   >               imported from `Hasql.Pool.Prelude' at library\Hasql\Pool.hs:16:1-25
2022-08-30T00:12:23.7653713Z hasql-pool                   >               (and originally defined in `GHC.Event.Windows.ConsoleEvent')
2022-08-30T00:12:23.7655989Z hasql-pool                   >            or `Hasql.Pool.Close', defined at library\Hasql\Pool.hs:20:31
2022-08-30T00:12:23.7660646Z hasql-pool                   >    |
2022-08-30T00:12:23.7674845Z hasql-pool                   > 82 |     writeTVar prevReuseToggle Close
2022-08-30T00:12:23.7675918Z hasql-pool                   >    |                               ^^^^^

[nikita-volkov]

should Windows be added to CI to verify this / prevent it in the future?

Sure! Let's do that.

Regarding the constructor conflict, I suggest to do one of the following:

1. Hide Close on the import of Hasql.Pool.Prelude
2. Rename constructors according to a convention of appending the type name to each constructor name. Notice that the other sum types in this package do follow that convention. See the UsageError type.
3. Simply use Boolean.

I think, the second option is better, since it makes the codebase more consistent. Also the third option seems fine too.

[robx]

I went with the Bool option now for simplicity (naming things is hard), and gave up on Windows CI for now, filed the failed attempt over at #21.