Create compat-kotlin-fixture module for AppMattus KotlinFixture migration

[MessiasLima]

Description

Problem: Teams using AppMattus KotlinFixture who want to migrate to Some must rewrite their test data generation code. The two libraries have similar capabilities but incompatible APIs (kotlinFixture() vs someSetup(), fixture<T>() vs some<T>(), repeatCount vs CollectionStrategy, etc.). This creates friction and blocks adoption.

User benefit: A dedicated compat module lets users migrate by changing only their Gradle dependency and import statements. All existing AppMattus patterns continue to work as thin aliases over Some's resolver chain.

Proposed solution: Add a new Gradle module compat-kotlin-fixture (artifact: dev.appoutlet:some-compat-kotlin-fixture) that depends on the core some artifact and provides extension functions / wrapper classes mapping the AppMattus public API to Some internals. The module is pure Kotlin with no additional runtime dependencies.

Scope

In scope:

• New Gradle module compat-kotlin-fixture under repository root with its own build.gradle.kts
• Top-level kotlinFixture() factory returning a wrapper around Some
• Fixture type alias / wrapper with invoke() overloads:
  • fixture<T>() → some<T>()
  • fixture(listOf(...)) → random element from list
  • fixture(1..5) → random element from range
  • fixture.asSequence<T>() → Sequence<T> generation
  • fixture.new { } → derived fixture configuration
• Configuration DSL aliases:
  • repeatCount { } → CollectionStrategy
  • subType<Super, Sub>() → type factory registration
  • factory<T> { } → factory(KClass) { }
  • property(PropertyRef) { } → property(KProperty1) { }
  • filter<T> { } → sequence filtering
  • random = Random(seed) → seed
  • nullabilityStrategy(...) → NullableStrategy mapping
  • optionalStrategy(...) → DefaultValueStrategy mapping
  • recursionStrategy(...) → circular reference handling
• Strategy enum/object aliases (e.g., NeverNullStrategy → NullableStrategy.NeverNull)
• Unit tests proving each alias produces the same behavior as the native Some API
• Dokka documentation and a short migration guide

Out of scope (initial release):

• loggingStrategy (no equivalent in Some today)
• constructorStrategy (no equivalent in Some today)
• fixture-javafaker / fixture-generex / fixture-kotest integrations
• Android-specific test artifacts

Acceptance criteria

• GIVEN a user has com.appmattus.fixture code using kotlinFixture() and fixture<T>()
  WHEN they replace the dependency with dev.appoutlet:some-compat-kotlin-fixture and update imports to dev.appoutlet.some.compat.kotlinfixture.*
  THEN the code compiles and generates the same fixture shapes without further changes
• GIVEN a user configures an AppMattus fixture with repeatCount { 3 }, factory<Int> { 42 }, and nullabilityStrategy(NeverNullStrategy)
  WHEN the compat layer builds the underlying SomeConfig
  THEN some<List<String>>() produces exactly 3 items, some<Int>() always returns 42, and some<String?>() never returns null
• GIVEN the compat-kotlin-fixture module is added to the project
  WHEN ./gradlew :compat-kotlin-fixture:test runs
  THEN all compat layer tests pass and Kover line coverage for the new module is ≥ 90%
• GIVEN a user calls fixture.asSequence<User>().take(5).toList() through the compat API
  WHEN the sequence is consumed
  THEN it produces 5 distinct generated User instances via the same resolver chain as some<User>()