Support multiple DataSources in the Spring Boot starter

[zantvoort]

Storm already ships Spring Boot integration; the 1.13.0 milestone tightens it further. This issue covers running against more than one database.

The starter creates a single ORMTemplate from the single DataSource, and StormTransactionAutoConfiguration binds to the first matching PlatformTransactionManager. Qualifier support exists for repository injection, but there is no supported way to run two templates against two DataSources with correctly matched transaction managers. Once the integration points are instance-scoped (#198), each template can carry its own connection provider and transaction bridge, and this becomes a wiring exercise.

Tasks:

• Per-DataSource ORMTemplate wiring with qualifiers
• Transaction manager matched per template instead of first-match
• Repository scanning that can target a specific template
• Docs with a two-database example

[zantvoort]

Cross-link: #219 adds multiple-database support to the Ktor plugin using package-based repository partitioning (each database block declares its repository packages, matching the existing repositories(...) narrowing). The starter work here should adopt the same convention so both integrations answer "which repositories belong to which database" the same way.

[zantvoort]

Completed by the 1.13.0 Spring integration work; closing with each task mapped to where it shipped:

• Transaction manager matched per template instead of first-match — feat!: Java/Kotlin transaction parity with a single-sourced Spring integration #226: SpringTransactionTemplateProvider receives the application's full transaction manager list and resolves the manager by DataSource identity per template. StormTransactionAutoConfiguration wires all managers.
• Repository scanning that can target a specific template — feat(spring): @EnableStormRepositories for switching on repository scanning #229: RepositoryBeanFactoryPostProcessor(basePackages, ormTemplateBeanName, repositoryPrefix) configuring constructors (and @EnableStormRepositories for the single-set case); one bean per repository set.
• Per-DataSource ORMTemplate wiring with qualifiers — supported as explicit wiring: qualified template beans composed with springOrmTemplate / the builder, each carrying its own connection provider and transaction bridge (instance-scoped since feat!: instance-scoped integration points with lazily bound transaction scopes #218). Verified end to end against a production application running nine DataSources over one database.
• Docs with a multi-DataSource example — the Multiple Data Sources section in spring-integration.md.

The starter additionally backs off cleanly in multi-DataSource contexts: with several DataSource beans and no @Primary, the auto-configured template and schema validation condition on a single candidate instead of failing the context (#226).

One reading of the first task remains deliberately unshipped: the starter auto-creating multiple templates from configuration. That was evaluated and declined — Spring Boot itself deliberately does not auto-configure multiple DataSources, topologies vary too widely for a configuration DSL to cover without becoming a framework of its own, and generated beans trade compile-time failures for property-binding failures. Explicit bean wiring with the configuring constructors is the supported path. If config-driven domain wiring shows concrete demand, that deserves a fresh issue with its own design.