Add support for include() statements in Bazel MODULE.bazel files

[markhallen]

What are you trying to accomplish?

Add support for Bazel's include() directive in MODULE.bazel files. This directive allows splitting MODULE.bazel content across multiple files, which is useful for organizing large module configurations.

Previously, Dependabot would fail with "BUILD file not found" errors when processing repositories that use include() because the included *.MODULE.bazel files and their associated BUILD files were not being fetched.

Fixes #13676

Anything you want to highlight for special attention from reviewers?

This implementation:

• Adds a new IncludeExtractor helper class following the same pattern as existing helpers (BzlFileFetcher, ModulePathExtractor)
• Reuses the existing PathConverter for Bazel label-to-path conversion
• Handles recursive includes (included files can themselves include other files)
• Fetches BUILD files for directories containing included files (required by Bazel)
• Supports both absolute (//path:file) and relative (:file) label syntax

The approach was chosen to maintain consistency with the existing codebase architecture and avoid code duplication.

How will you know you've accomplished your goal?

• Test coverage: Added comprehensive tests covering basic includes, nested includes, and missing file handling. All 50 file_fetcher tests pass.
• No regressions: The existing 42 Bazel file_fetcher tests continue to pass, ensuring no regressions in existing functionality.
• Limitation: The original issue did not provide a test repository to validate against. The implementation is based on the Bazel documentation for include() and the patterns observed in the linked PR Add support for .bzl files, local overrides, and downloader configs in Bazel file fetcher #13586.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.