feat: Handle oneOf/anyOf with inline object variants

[nikcio]

Changes

Previously, oneOf/anyOf unions with inline (non-ref) object variants degraded to object, losing type information. Now, inline object variants are hoisted to named records, and the union is emitted as an abstract record with [JsonDerivedType] attributes referencing both ref variants and hoisted inline objects.

Before

value:
  oneOf:
    - $ref: A                    # ref variant
    - type: object                # inline variant → degraded to object
        properties:
          x: { type: string }

Property typed as object? — no type safety, no JSON polymorphism.

After

Property typed as MyRecordValue? — an abstract record with:

• [JsonDerivedType(typeof(A), "A")]
• [JsonDerivedType(typeof(MyRecordValueVariant2), "MyRecordValueVariant2")]

The inline object is hoisted to MyRecordValueVariant2 record.

Implementation

• Extend IsInlineRefUnion to IsInlineUnion: accepts inline objects alongside ref variants
• In TryHoistPropertySchema, hoist inline object variants before hoisting the union itself
• In DiscoverInlineObjects, scan oneOf/anyOf variants for component-level union schemas
• In EmitSimpleUnion, resolve inline object variants to their hoisted type names
• Add TypeResolver.GetInlineObjectTypeName for looking up hoisted names

Limitation

Unions with primitive variants (e.g. oneOf: [{type: string}, {type: integer}]) still degrade to object since primitives can't be hoisted to records. This could be addressed in a future PR with a custom JsonConverter.

Testing

All 264 tests pass (260 existing + 4 new). New tests include compilation with TreatWarningsAsErrors.