feat: classify conditional imports

[TristanKruse]

Pull Request

Adds first-class classification for conditional imports inside try blocks that handle ImportError or ModuleNotFoundError.

These imports are now marked with ImportKind.CONDITIONAL_IMPORT, allowing dependency graphs and reports to distinguish optional/fallback dependencies from regular runtime imports.

This PR includes regression tests for conditional imports in raw import extraction and graph extraction, plus a short README note documenting the behavior.

Change Type

• Bug fix
• Feature
• Documentation
• Refactoring

[TristanKruse]

Validation:

• pytest tests\common\test_extract_graph.py --tb=short -q: 29 passed
• pytest --tb=short -q: 267 passed
• ruff check src\archunitpython\common\extraction\graph.py src\archunitpython\common\extraction\extract_graph.py tests\common\test_extract_graph.py: passed
• mypy src\archunitpython\ --ignore-missing-imports: passed
• git diff --check: passed

Note: full ruff check src tests still reports existing baseline cleanup issues, which are handled separately in #31.

[lukasniessen-bain]

I found one blocker around relative conditional imports.

from . import fallback inside a handled ImportError block is now classified as CONDITIONAL_IMPORT, but the resolver only has the stored import name '.' to work with. That means the graph resolves the package path rather than the sibling module being imported. This is a common optional fallback pattern, so it can silently produce the wrong dependency edge for the exact behavior this PR is adding.

Please add coverage for conditional relative imports, especially from . import module, and adjust the extraction/resolution path so the conditional context does not erase the relative import semantics needed to resolve the target correctly.