Reorganize folder structure: group Resolvers with their related Strategies

[MessiasLima]

Description

Re-organize the source tree so that every logical type gets its own sub-package containing both its resolver and its strategy (if any). Resolvers and their corresponding Strategies have a tight 1-to-1 (or 1-to-many) relationship. Keeping them in separate directories (resolver/ vs config/) makes it harder to discover which strategies influence which resolver, refactor a resolver without jumping between two packages, and add new type support (you have to touch files in two unrelated folders).

• Scope and constraints

  • Only move files; no behavioural changes.
  • Test package structure must mirror the new source structure.
  • SomeConfig and SomeConfigBuilder stay in config/ because they are not resolver-specific.
  • The Strategy.kt marker interface may move to a base/ or core/ sub-package or remain at the top of resolver/.

• References

  • AGENTS.md — contains the current resolver registration order and naming conventions.
  • CONTRIBUTING.md — may need a note about the new package-by-type convention.

Scope

In scope:

• Reorganize src/main/kotlin/dev/appoutlet/some/resolver/ into sub-packages by type (e.g. string/, collection/, nullable/, class/, enum/, sealed/, uuid/, instant/, duration/, localDate/, bigNumber/, custom/).
• Move related strategy files from config/ into the corresponding resolver sub-packages.
• Update all package declarations and imports across the codebase.
• Mirror the new package structure in src/test/kotlin/dev/appoutlet/some/resolver/.

Out of scope:

• Refactoring resolver logic or strategy behaviour.
• Changing the public API (some<T>(), someSetup {}, etc.).
• Adding new resolvers or strategies.

Acceptance criteria

• All resolvers and their related strategies live in the same sub-package of resolver/.
• Strategy.kt (marker interface) is either in a base/ or core/ sub-package or remains at the top of resolver/.
• SomeConfig / SomeConfigBuilder stay in config/.
• All existing tests compile and pass without behavioural changes.
• No imports use the old package paths.
• The AGENTS.md resolver registration order documentation is updated to reflect the new paths.
• Detekt / Ktlint checks pass after the move.

Additional information

The exact grouping names are open to discussion; the goal is co-location of closely related files. For example:

resolver/
├── string/
│   ├── StringResolver.kt
│   └── StringStrategy.kt
├── collection/
│   ├── ListResolver.kt
│   ├── SetResolver.kt
│   ├── MapResolver.kt
│   ├── ArrayResolver.kt
│   └── CollectionStrategy.kt
├── nullable/
│   ├── NullableResolver.kt
│   └── NullableStrategy.kt
├── class/
│   ├── ClassResolver.kt
│   └── DefaultValueStrategy.kt
└── ...

Open question: should primitive resolvers (IntResolver, LongResolver, etc.) be grouped together in a primitive/ package, or given individual packages?

[google-labs-jules]

Jules is on it. When finished, you will see another comment and be able to review a PR.

[google-labs-jules]

Ready for a review! A PR has been created.