Consider introducing OpenRewrite recipes for Docling Java

Even though the project is not GA yet, it would be nice to provide OpenRewrite recipes to automate refactoring when updating to newer versions, taking care of breaking changes without any manual intervention.

For example, we changed some packages in version 0.2 and 0.3.

For now, I publish OpenRewrite recipes as part of my [Arconia Migrations](https://github.com/arconia-io/arconia-migrations) project, which is a catalog of open-source recipes for JUnit, Testcontainers, Spring, Arconia, and other Java-related libraries.

- [io.arconia.rewrite.docling.UpgradeDocling_0_2](https://github.com/arconia-io/arconia-migrations/blob/main/rewrite-docling/src/main/resources/META-INF/rewrite/docling/docling-0-2.yml)
- [io.arconia.rewrite.docling.UpgradeDocling_0_3](https://github.com/arconia-io/arconia-migrations/blob/main/rewrite-docling/src/main/resources/META-INF/rewrite/docling/docling-0-3.yml).

They can be run from the `rewrite-docling` module (fully dedicated to Docling) using any of the OpenRewrite approaches, including the Maven plugin:

```shell
./mvnw -U org.openrewrite.maven:rewrite-maven-plugin:run \
-Drewrite.recipeArtifactCoordinates=io.arconia.migrations:rewrite-docling:LATEST \
-Drewrite.activeRecipes=io.arconia.rewrite.docling.UpgradeDocling_0_3
```

I'd be happy to contribute those recipes upstream, if we decide to adopt OpenRewrite. If we do, my suggestion would be to keep the recipes separate from the main packages, and with a separate release lifecycle. It's likely we need to make changes to recipes outside the main release lifecycle. Also, some recipes need the new version already published in order to be tested, so we can't keep the recipes in the same place. If not, I'd be happy to continue maintaining them in my project :)