1318: Update to Kotlin 2.1.20

[steve-the-edwards]

Associated AGP, Gradle, and friends changes.

Specify kotlin.languageVersion=1.9 while we still use it in 1.9 apps.

(Also I added a .yarnrc file so we don't override the yarnpkg registry unintentionally)

This stands on its own as a worthwhile thing to do, but I'm doing it now because it unlocks being able to use vanniketch's publishing plugin 0.28.0 (PR), which is important for being able to seamlessly update Sonatype Central location (PR).

Note that we had a lot of @UnsafeVariance notes and conflicting variance specifications - e.g., in specified generics used in the out position and vice versa. The ability to do this was removed with Kotlin 2.0 - @UnsafeVariance is just ignored. See, e.g., https://youtrack.jetbrains.com/issue/KTLC-72/K2-Stop-relying-on-the-presence-of-UnsafeVariance-using-for-contravariant-parameters

I did some spelunking (149ab27, e50a0bb, #56 and friends) back to the beginning and I cannot find any specific explicit decision or justification for use of in PropsT and out OutputT, out RenderingT.

As such, my conclusion is just that we started there naturally because that is logically how those generics are "used" (e.g., props are passed in, output passed out; this regardless of whether or not the code using them is only producer, or only consumer as per the Kotlin generics declaration-site variance rules - https://kotlinlang.org/docs/generics.html#declaration-site-variance).

Also, with the exception of sometimes using, e.g., Nothing as a subtype of all types in order to type utilities that did not have to deal with the RenderingT we don't actually make use of this variance much with Workflows., E.g., we are not relying on Workflow<String, String, String> being a subclass of Workflow<Object, Object, Object>. This is at least because when workflows are passed as a parameter, we are expecting a particular type of a Workflow (including specific generic types). We do not have (AFAIK) much utility that operates on a set of Workflow's whose generic types share some common supertype.

I can prove this better running this snapshot in our internal build.

@zach-klippenstein , @rjrjr do you have any other recollections/thoughts on this?

Closes #1318