feat(graph): add --reduce option to to-dot command

[dhellmann]

Add a new --reduce flag to the graph to-dot command that filters the
dependency graph to only include nodes with fromager customizations
(overrides, settings, patches, plugins, or pre-built wheels).

The reduced graph preserves dependency relationships by creating direct
edges between customized nodes, skipping intermediate nodes without
customizations. Original requirement specifications are tracked and
displayed in edge labels for better clarity.

Key changes:

• Add --reduce command line option to to-dot command
• Implement has_customizations() to identify nodes with customizations
• Implement reduce_graph() to build filtered dependency relationships
• Track original requirement strings for proper edge labeling
• Use req_type.is_build_requirement property for build dependency checks

This feature helps visualize which packages in a dependency tree actually
have fromager customizations while maintaining essential dependency
relationships.

Fixes #715

Cursor chat transcript: https://gist.github.com/dhellmann/e362954e00a7270dcc71037382f53853

[dhellmann]

Here are a few sample output files showing the difference between a full graph and a reduced graph:

docling-graph.json.dot.pdf
docling-graph.json-reduced.dot.pdf
torch-cuda-graph.json.dot.pdf
torch-cuda-graph.json-reduced.dot.pdf

[LalatenduMohanty]

@dhellmann can you pass a graph file which has packages with customization, so that it would be easier for me to test the PR?

[dhellmann]

@dhellmann can you pass a graph file which has packages with customization, so that it would be easier for me to test the PR?

The graph file itself doesn't record which packages had customizations, though we could add that. I'll upload the graph files I used to produce the PDFs but you'll have to run fromager with the context from our downstream configuration repo to get the same output.

docling-graph.json

torch-cuda-graph.json

[LalatenduMohanty]

I will suggest that we break the reduce_graph() to smaller methods. Currently it is doing few things. Smaller functions will improve its readability.

[dhellmann]

How would you break it up?

[LalatenduMohanty]

@dhellmann IMO we should merge the PR as it is and we can take up refactoring in a separate issue. I would be happy to work on it.

[LalatenduMohanty]

Here is the idea I had (using Cursor), I have the code locally as well.

reduce_graph() function can be broken down into 4 focused helper functions:

1. _get_nodes_for_reduction() (9 lines)
   Purpose: Determine starting node set based on install_only flag
   Responsibility: Node selection logic

2. _find_customized_nodes() (10 lines)
   Purpose: Filter nodes to find only those with customizations
   Responsibility: Node filtering logic

3. _find_customized_dependencies_for_node() (33 lines)
   Purpose: Complex graph traversal for a single node
   Responsibility: Depth-first search algorithm
   Most complex: Contains the core traversal logic

4. _build_reduced_dependency_map() (8 lines)
   Purpose: Orchestrate dependency mapping for all nodes
   Responsibility: Coordinate traversal across all customized nodes

5. reduce_graph() (Refactored, 13 lines)
   Clear flow: Get nodes → Find customized → Build dependencies → Return

[rd4398]

This looks good! I see there are few comments on MR so I will wait for them to be resolved before I hit approve