SI-8023 Fix symbol-completion-order type var pattern bug

Removing the `isComplete` check altogether leads to cycles in,
for instatnce, F-bound type parameters:

    trait LSO[+A, +Repr <: LSO[A, Repr]] // error: illegal cyclic reference involving type Repr

But, I believe that we can (and must) eagerly initialize the type
parameter symbols if we are typechecking a pattern.

While this appeared to regress in 2.11.x, but the problem was in fact
dormant and was merely uncovered in the fix for SI-7756, 3df1d77fc.
SI-8023 Address review comments around typedHigherKindedType

  - Make `WildCardType` kind polymorphic
  - Factory methods for expected kinds. They are still just
    `Type`-s, though.
  - Check if the type parameter is initialized, rather than
    its owner.
  - Take advantage of these to cleanup `typedAppliedTypeTree`

TODO: is this comment totally accurate? If so, should we
refactor `Kind.FromParams(tparams)` to `Kind.Arity(tparams.length)`?

     // @M: kind-arity checking is done here and in adapt,
     //     full kind-checking is in checkKindBounds (in Infer)
Merge pull request #3212 from retronym/ticket/8023

SI-8023 Fix symbol-completion-order bug of type var patterns