Add Info about artifacts to Migration Guide

Describe all changes in our artifacts.
Refer to https://kotlin.github.io/dataframe/modules.html

Add an "Artifacts / Modules" section to the 1.0 Migration Guide (clarifies #1779)

Motivation

Between 0.15 and 1.0 the set of published Maven artifacts changed significantly (functionality was split into new modules, some modules were added, the general dataframe artifact's composition changed, and the plugins story changed). Users upgrading from 0.15 currently have to piece this together from the Modules page and scattered mentions in the guide. The Migration Guide should have one dedicated section that lists exactly what changed at the artifact/dependency level, so upgrading users know which dependencies to add, remove, or rename.

This is the concrete, scoped version of #1779 ("Describe all changes in our artifacts"), which is currently in Needs_clarification.

Where it goes

docs/StardustDocs/topics/MigrationTo_1_0.md already has a commented-out placeholder for this (tied to #1630):

<!--TODO (https://github.com/Kotlin/dataframe/issues/1630)
## Modules
## Compiler Plugin
## Changes in working with JDBC
-->

The new section should replace/flesh out the ## Modules part of that placeholder. Coordinate with #1630 so the two don't diverge.

Scope — artifact changes to document (0.15 → 1.0)

Describe, as a 0.15 → 1.0 table plus short notes, at least:

• New dataframe-csv module — CSV/TSV IO moved out of core into its own module (Deephaven-based); included by default in the general dataframe artifact and in %use dataframe. (Cross-link the existing "Migration to Deephaven CSV" section.)
• dataframe-json as a standalone module — and the fact that it is pulled in transitively by dataframe-csv / dataframe-excel (with the documented exclude escape hatch).
• OpenAPI split — dataframe-openapi (runtime, add to use generated schemas) vs the new dataframe-openapi-generator (generation, used by Gradle/KSP/Jupyter).
• New experimental dataframe-geo module (requires the OSGeo repository).
• General dataframe artifact composition — now = all core + IO modules, excluding experimental ones; state what moved in/out vs 0.15.
• Plugins changes — the new official Kotlin compiler plugin kotlin.plugin.dataframe; the Gradle plugin kotlinx.dataframe and KSP symbol-processor-all being under consideration for deprecation, with data-schema generation now via dedicated methods.
• Coordinates / naming — confirm any artifact groupId/artifactId renames or coordinate changes since 0.15 (see open questions).

For each: what the user must change in their build file (add/remove/rename dependency).

Open questions (the "needs clarification" part)

• Baseline: is the guide strictly 0.15 → 1.0, or should it also mention intermediate 1.0-Beta artifact changes?
• Were any artifacts renamed or removed (not just added/split) since 0.15? If so, list old→new coordinates explicitly.
• Should the compiler-plugin / Gradle-plugin / JDBC details live here or in the sibling ## Compiler Plugin / ## Changes in working with JDBC placeholder sections (to avoid duplication with #1630)?
• Minimum Kotlin/Gradle version bumps that affect artifact usage — in scope here or elsewhere?

Acceptance criteria

• MigrationTo_1_0.md has a dedicated Modules / Artifacts section (replacing the commented-out ## Modules placeholder).
• It lists every artifact-level change (added / split / moved / deprecated) with a 0.15 → 1.0 mapping and the required build-file change.
• It cross-links the Modules page and the existing CSV/Deephaven migration section rather than duplicating them.
• The open questions above are resolved (or explicitly deferred) before the section is written.
• Alignment with #1630 is confirmed so the Modules / Compiler Plugin / JDBC sections don't overlap.

Start with docs/StardustDocs/topics/MigrationTo_1_0.md and the Modules page, then review the existing CSV/Deephaven migration section and issue #1630. Resolve the listed artifact, coordinate, version-scope, and section-boundary questions before documenting the 0.15 → 1.0 dependency changes. Done means a dedicated Modules / Artifacts section with the mapping, required build-file changes, cross-links, and no overlap with #1630.