Type inference for ... is more fragile in GHC-9.*

[gromakovsky]

This issue was first noticed in #243. Consider the following code:

super :: [()] -> Bool
super = null ... asFun (: [])

asFun :: (a -> b) -> a -> b
asFun = id

AFAIU, without asFun it compiles successfully with GHC-8., but fails to compile with GHC-9. which complains about ambiguous types. See comments in that PR.

There are several things to do:

1. Report it as a potential bug in GHC. I am not entirely sure it's a bug because incoherent instances are involved which implies some non-determinism. We can just report it as is and let GHC developers figure it out OR try to dive deeper into it and think whether GHC complies with its specification in this case.
2. Figure out whether this implementation of ... is safe at all because incoherent instances generally look scary.

Maybe we'll deprecate ... as result. Hence, setting type as breaking.