Reject dodgy scoping in associated family instance RHSes

Commit e63518f5 tried to push all of the logic
of detecting out-of-scope type variables on the RHSes of associated type family
instances to `GHC.Tc.Validity` by deleting a similar check in the renamer.
Unfortunately, this commit went a little too far, as there are some corner
cases that `GHC.Tc.Validity` doesn't detect. Consider this example:

```hs
class C a where
  data D a

instance forall a. C Int where
  data instance D Int = MkD a
```

If this program isn't rejected by the time it reaches the typechecker, then
GHC will believe the `a` in `MkD a` is existentially quantified and accept it.
This is almost surely not what the user wants! The simplest way to reject
programs like this is to restore the old validity check in the renamer
(search for `improperly_scoped` in `rnFamEqn`).

Note that this is technically a breaking change, since the program in the
`polykinds/T9574` test case (which previously compiled) will now be rejected:

```hs
instance Funct ('KProxy :: KProxy o) where
    type Codomain 'KProxy = NatTr (Proxy :: o -> *)
```

This is because the `o` on the RHS will now be rejected for being out of scope.
Luckily, this is simple to repair:

```hs
instance Funct ('KProxy :: KProxy o) where
    type Codomain ('KProxy @o) = NatTr (Proxy :: o -> *)
```

All of the discussion is now a part of the revamped
`Note [Renaming associated types]` in `GHC.Rename.Module`.

A different design would be to make associated type family instances have
completely separate scoping from the parent instance declaration, much like
how associated type family default declarations work today. See the discussion
beginning at #18021 (comment 265729) for
more on this point. This, however, would break even more programs that are
accepted today and likely warrants a GHC proposal before going forward. In the
meantime, this patch fixes the issue described in #18021 in the least invasive
way possible. There are programs that are accepted today that will no longer
be accepted after this patch, but they are arguably pathological programs, and
they are simple to repair.

Fixes #18021.