Refactor LLM client auto-configuration structure

- Removed `KoogAutoConfiguration` and related legacy configuration
files.
- Introduced modular `LLM` provider-specific auto-configuration classes
(e.g., `OpenAILLMAutoConfiguration`).
- Updated test setup to align with the new modular configuration.
- Enhanced property validation with `enabled` flag support for
finer-grained control.
- Introduced a `String.masked` extension to obfuscate sensitive string
parts. Added test coverage for various input scenarios, including custom
mask characters and edge cases.
- Updated `KoogAutoConfigurationTest` to include scenarios where
providers are explicitly disabled.
- Refactored parameterized tests to use `textBlock = PROVIDERS` with
`@CsvSource`.
- Adjusted `ApplicationContextRunner` configuration logic for clean test
scenarios.
- Introduced `ignoreUnknownFields` to all `ConfigurationProperties` to
improve flexibility with unmapped fields.
- Expanded property documentation for all LLM clients (e.g., OpenAI,
Google, Anthropic) to include detailed descriptions, usage examples, and
retry behavior.
- Improved autowiring safety with `@ConditionalOnBean` for LLM-specific
executors.
- Updated `spring-boot.md` to detail `enabled` flags and their default
behavior for LLM providers.
- Improved clarity by reformatting the supported provider list.
- Added explanations for default base URLs and explicit activation for
non-API-key providers (e.g., Ollama).

A blog post about writing Spring Boot starters is
[here](https://kpavlov.me/blog/spring-boot-starters)

**NB! Tests need a split and some love, but this PR is already big
enough. I will refactor them separately.**

## Motivation and Context

- The Spring Boot configuration in general is not very Spring Boot
idiomatic
- The current Spring Boot starter does not expose LLM Clients. In order
to get the LLM client in the application, developers have to use
reflection to a get a field from the executor 🤯
- All configuration is encapsulated in one file, which makes
extensibility difficult (SRP is violated).
- Defaults are hardcoded in classes instead of being provided in the
resources
- Ollama is enabled by the presence of the base URL, which is
interesting.
- There is no explicit way to disable an LLM provider: no `enabled=true`
property

## Breaking Changes

- AutoConfiguration classes moved to their respective packages
- Ollama provider needs `ai.koog.ollama.enabled=true` to be set
explicitly in order to activate.

---

#### Type of the changes
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
- [x] Tests improvement
- [x] Refactoring

#### Checklist
- [x] The pull request has a description of the proposed change
- [ ] I read the [Contributing
Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md)
before opening the pull request
- [x] The pull request uses **`develop`** as the base branch
- [ ] Tests for the changes have been added
- [ ] All new and existing tests passed

##### Additional steps for pull requests adding a new feature
- [ ] An issue describing the proposed change exists
- [ ] The pull request includes a link to the issue
- [ ] The change was discussed and approved in the issue
- [x] Docs have been added / updated

(cherry picked from commit 5a05fed)

Refactor LLM client auto-configuration structure

- Removed `KoogAutoConfiguration` and related legacy configuration
files.
- Introduced modular `LLM` provider-specific auto-configuration classes
(e.g., `OpenAILLMAutoConfiguration`).
- Updated test setup to align with the new modular configuration.
- Enhanced property validation with `enabled` flag support for
finer-grained control.
- Introduced a `String.masked` extension to obfuscate sensitive string
parts. Added test coverage for various input scenarios, including custom
mask characters and edge cases.
- Updated `KoogAutoConfigurationTest` to include scenarios where
providers are explicitly disabled.
- Refactored parameterized tests to use `textBlock = PROVIDERS` with
`@CsvSource`.
- Adjusted `ApplicationContextRunner` configuration logic for clean test
scenarios.
- Introduced `ignoreUnknownFields` to all `ConfigurationProperties` to
improve flexibility with unmapped fields.
- Expanded property documentation for all LLM clients (e.g., OpenAI,
Google, Anthropic) to include detailed descriptions, usage examples, and
retry behavior.
- Improved autowiring safety with `@ConditionalOnBean` for LLM-specific
executors.
- Updated `spring-boot.md` to detail `enabled` flags and their default
behavior for LLM providers.
- Improved clarity by reformatting the supported provider list.
- Added explanations for default base URLs and explicit activation for
non-API-key providers (e.g., Ollama).

A blog post about writing Spring Boot starters is
[here](https://kpavlov.me/blog/spring-boot-starters)

**NB! Tests need a split and some love, but this PR is already big
enough. I will refactor them separately.**

## Motivation and Context

- The Spring Boot configuration in general is not very Spring Boot
idiomatic
- The current Spring Boot starter does not expose LLM Clients. In order
to get the LLM client in the application, developers have to use
reflection to a get a field from the executor 🤯
- All configuration is encapsulated in one file, which makes
extensibility difficult (SRP is violated).
- Defaults are hardcoded in classes instead of being provided in the
resources
- Ollama is enabled by the presence of the base URL, which is
interesting.
- There is no explicit way to disable an LLM provider: no `enabled=true`
property

## Breaking Changes

- AutoConfiguration classes moved to their respective packages
- Ollama provider needs `ai.koog.ollama.enabled=true` to be set
explicitly in order to activate.

---

#### Type of the changes
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
- [x] Tests improvement
- [x] Refactoring

#### Checklist
- [x] The pull request has a description of the proposed change
- [ ] I read the [Contributing
Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md)
before opening the pull request
- [x] The pull request uses **`develop`** as the base branch
- [ ] Tests for the changes have been added
- [ ] All new and existing tests passed

##### Additional steps for pull requests adding a new feature
- [ ] An issue describing the proposed change exists
- [ ] The pull request includes a link to the issue
- [ ] The change was discussed and approved in the issue
- [x] Docs have been added / updated

(cherry picked from commit 5a05fed)