Add expectCovariantWorkflow for expecting via workflow classes that have generics

[steve-the-edwards]

Recently we removed the in PropsT and out OutputT declaration site variance specifications due to the UnsafeVariance usage we had within RenderContext and the fact that Kotlin 2+ no longer allowed this (see #1320 && #1328).

However, any expectWorkflow( workflowType = SomeWorkflowType::class) calls where SomeWorkflowType was an interface or class that still contained generics (rather than fully specified types), was failing to compile. It simply reported an expectation of Nothing - which is not a helpful compiler error really that I could find. The problem though, was that these types could no longer be covariant through the OutputT hierarchy. As such, I have added an expectCovariantWorkflow where the class can be a supertype that includes generics, but the childOutputType and childRenderingType must be specified directly with KType and then these are verified against the workflow invocations.

So far, we have mainly seen this be a problem when there is a factory constructing child workflow instances and the tests do not have access to those instances (or a good class type) in order to expect them.

So this adds a new testing API - expectCovariantWorkflow where the base class, and the OutputT KType and RenderingT KType are all specified explicitly so they can be matched.

There are still scenarios where the type system can't keep up - namely if you have nested generics in your generic types. I still do not totally understand when the RenderTester ChildRenderInvocation will successfully and won't successfully determine these types (I have seen both). I have not gotten to the bottom of that, but instead preferred to provide an 'opt-out' of nested generic verification as is needed.

To make it easier to work with these edge cases I added a parameter to specify the levels of recursive verification to do on generics.