## Don't drop derived quantified constraints

In looking at the way quantified constraints are handled, I noticed that we drop derived quantified constraints (in `TcCanonical.solveForAll`

). I don't see a reason why this is a good idea. And indeed, it causes trouble:

```
{-# LANGUAGE QuantifiedConstraints, MultiParamTypeClasses,
KindSignatures, FlexibleInstances, TypeFamilies #-}
module Bug where
import Data.Kind
class (forall (a :: Type -> Type). a b ~ a c) => C b c
instance C a a
class (b ~ c) => D b c
instance D a a
foo :: C a b => a -> b
foo = undefined
bar = foo
food :: D a b => a -> b
food = undefined
bard = food
```

`C`

and `D`

should really behave identically. Yet `bar`

is rejected while `bard`

is accepted.

Note that the monomorphism restriction forces us to solve, not quantify over, the `C`

and `D`

constraints. This is intentional in this test case.

Normally, the superclasses of a wanted are emitted as derived constraints. In the case of `bard`

, we start with `[W] D alpha beta`

, which doesn't make progress. So we get `[D] alpha ~ beta`

, which unifies the two, and then `[W] D alpha alpha`

is easily dispatched. But in `bar`

the `[D] forall a. a alpha ~ a beta`

is dropped, leading to rejection.

The kind signature in the test case is needed because of #17562 (closed).