feat: kotlin xlr types

[rafbcampos]

Summary

• Adds a full Kotlin type system for XLR, mirroring the existing TypeScript types under types/kotlin/
• Implements a manual JSON deserializer (XlrDeserializer) using kotlinx.serialization to parse XLR JSON documents into strongly-typed Kotlin data classes
• Includes type guard utility functions (XlrGuards) for common checks like primitive types, asset/binding/expression refs, and asset type extraction
• Adds utility types (XlrUtility) for capabilities, manifests, and transform functions
• Provides comprehensive test coverage for types, deserialization, and guards
• Sets up Bazel build with rules_kotlin, kotlinx-serialization compiler plugin, and ktlint for linting

Build changes:

• Updated MODULE.bazel to add rules_kotlin and kotlinx-serialization dependencies
• Added root BUILD.bazel kotlin compiler options
• Minor CI config update in .circleci/config.yml

📦 Published PR as canary version: 0.2.0--canary.4.100

Try this version out locally by upgrading relevant packages to 0.2.0--canary.4.100

[rafbcampos]

/canary

[codecov]

Codecov Report

❌ Patch coverage is 97.20430% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 65.47%. Comparing base (6e01f17) to head (89ecc69).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...rc/main/kotlin/com/intuit/playerui/xlr/XlrTypes.kt	97.62%	4 Missing and 5 partials ⚠️
.../kotlin/com/intuit/playerui/xlr/XlrDeserializer.kt	88.23%	0 Missing and 2 partials ⚠️
...c/main/kotlin/com/intuit/playerui/xlr/XlrGuards.kt	94.11%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main       #4      +/-   ##
==========================================
+ Coverage   61.88%   65.47%   +3.59%     
==========================================
  Files          22       28       +6     
  Lines        4106     4571     +465     
  Branches      706      733      +27     
==========================================
+ Hits         2541     2993     +452     
- Misses       1558     1562       +4     
- Partials        7       16       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[brocollie08]

are these @Transient properties not conflicting with the @SerialName, are both needed

[rafbcampos]

My understand is that @SerialName sets the polymorphic discriminator value ("type": "string" in JSON) and @Transient prevents type from being serialized as a regular field, avoiding a clash with the discriminator. The type property itself exists purely as a Kotlin convenience so you can do node.type without pattern matching. If you removed @Transient, serialization would fail. If you removed the type property entirely, you'd lose programmatic access to the type string (though you could use when(node) instead).