Parse schema using FIR instead of reflection

[JakeWharton]

Switch to using FIR so that we can:

• Parse default expressions on properties

  @Widget(1)
  data class Button(
    @Property(1) val bgColor: String = "red",
  )

  will change the generated code:

   @Composable
   fun Button(
  -  bgColor: String,
  +  bgColor: String = "red",
   ) { .. }

• Retain comments on the type and property.

  /** Hey I'm a button */
  @Widget(1)
  data class Button(
    /** Background color, will be darkened 10% for touch state. */
    val bgColor: String,
  )

  will change the generated code:

  +/** Hey I'm a button */
   interface Button {
  +  /** Background color, will be darkened 10% for touch state. */
     fun bgColor(bgColor: String)
   }

  and

  +/** Hey I'm a button */
   @Composable
   fun Button(
  +  /** Background color, will be darkened 10% for touch state. */
     bgColor: String,
   ) { ... }

• Capture parameter names on event lambdas.

  @Widget(1)
  data class Thing(
    @Property(1) val someEvent: (x: Int, y: Int) -> Unit,
  )

  will change the generated code:

   @Composable
   fun Thing(
  -  someEvent: (Int, Int) -> Unit,
  +  someEvent: (x: Int, y: Int) -> Unit,
   ) { .. }

[JakeWharton]

UAST would also give us default expressions without requiring an annotation

[JakeWharton]

We could also theoretically use the new FIR of the compiler.

[JakeWharton]

UAST bootstrap can now be copied from the lint support.

[JakeWharton]

I have parsing somewhat working using PSI.

The biggest problem I foresee is that we currently parse the schema in multiple places with reflection and we do that by consuming a jar of the compiled Kotlin on the classpath. With PSI we can only access things like default expressions and comments in source. This means that we do not get them from dependencies.

There's two problems with this:

• We currently re-parse the schema in each codegen project. When you point a widget and compose generator project at your schema they each parse it with reflection and then do codegen.

  In order to support this case we need to manipulate the output artifact so that it contains a parsed model. The easiest way that I think we can accomplish this is by embedding a Java resource of the parsed JSON model into the jar. Downstream consumers can look up the resource and directly use the parsed model.

• For schema dependencies we currently see them and then parse them as their own schema. This mostly affects the protocol generation, but the regular widget generation also needs the name. I think we can get away with allowing the regular PSI-based parsing resolve these remote schema types and gain access to what we need. If not, it can load the aforementioned JSON as well.

[JakeWharton]

The only interesting thing from this migration is how to handle the default expression change.

For the first implementation we will respect the @Default annotation and ignore the default expression. This retains the behavior of the reflection parser today.

Then, once that is working, we will delete the @Default annotation and require migration to regular expressions.

[JakeWharton]

Need to switch JSON generation task to be added as a resource-generating task once this is complete. Currently we pack it into the jar which doesn't always work.