Allow providing custom `DocumentationSource` implementation

Hi, and thanks again for your work on Spring Modulith!

This is a follow-up to GH-1133, where I described problems with SpringModulithProcessor and javadoc.json generation in a multi-module Gradle project.

To recap briefly:

• I have a multi-module Gradle project with application modules in different Gradle modules.
• After the fix for GH-1133, each Gradle module now correctly produces its own build/generated-spring-modulith/javadoc.json file – thank you for that!
• However, SpringModulithDocumentationSource still only uses the single javadoc.json resolved via BuildSystemUtils.getTargetResource(METADATA_FILE), which points to the “root” location.
• As a result, JavaDocs from the submodules are still not included in the final SpringModulithDocumentationSource#metadata collection.

I completely understand that designing a generic solution that correctly aggregates metadata from multiple build modules (Gradle and Maven, different project layouts, etc.) might be non-trivial and take some time to get right without breaking existing setups.

To unblock my use case and similar setups, I would like to propose a smaller, more targeted change:

Proposal

Allow DocumentationSource to be pluggable, similar to ApplicationModuleDetectionStrategy:

• Reuse the existing lookup mechanism (generalized if needed) so it can resolve both ApplicationModuleDetectionStrategy and DocumentationSource.
• If a custom DocumentationSource is present, use it; otherwise, fall back to the current behavior using BuildSystemUtils.getTargetResource(METADATA_FILE), preserving full backward compatibility.

With this hook, I can provide a custom DocumentationSource that locates and aggregates all module-level generated-spring-modulith/javadoc.json files for my project.

Benefits

• Unblocks multi-module documentation aggregation without requiring an immediate global change in how metadata is discovered.
• Keeps existing behavior unchanged if no custom implementation is provided.
• Provides a flexible hook for other build setups or documentation strategies in the future.

Please let me know if you’re open to this extension point or if you’d prefer a different shape for the API.

Start by reading DocumentationSource, SpringModulithDocumentationSource, ApplicationModuleDetectionStrategy, and BuildSystemUtils.getTargetResource(METADATA_FILE). Trace how the current DocumentationSource and metadata collection are selected, then define the fallback behavior for a custom implementation. Done means a pluggable DocumentationSource can aggregate module metadata while preserving the existing default behavior.