[NOT READY FOR REVIEW] config mk to py, reduce dependency on make

[oharboe]

Platform config.py files

Each platform directory now has a config.py alongside config.mk.
The config.mk is a one-liner shim that calls config.py and evals
the output as Make code -- the same pattern as defaults.py in
variables.mk.

Why

Platform config.mk files use Make syntax to define ~30-100
environment variables per platform. These variables flow through to
TCL scripts via $::env(...). The Make syntax is untestable: there
is no way to write unit tests for variable resolution, especially
for asap7's $(foreach)/$(eval) VT variant generation.

Moving the logic to Python enables:

• Unit testing: 137 pytest tests verify every Make construct
  (conditionals, variable indirection, template expansion, globbing,
  corner selection, VT loops) produces correct output.

• JSON output for bazel-orfs: config.py --format=json returns a
  flat dict of all variables. bazel-orfs can call this directly
  instead of shelling out to Make, eliminating Make as a runtime
  dependency (Plan E, Phase 2).

• Piecemeal migration: each platform migrated independently.
  Make users see zero behavior change.

How it works

  Make flow (unchanged):
    Makefile -> variables.mk -> include config.mk (shim)
                                  -> $(shell python config.py)
                                  -> $(foreach)/$(eval) output as Make code

  bazel-orfs (new capability):
    rules.bzl -> python config.py --format=json -> JSON dict

The shim in each config.mk:

$(foreach line,$(shell $(PYTHON_EXE) $(PLATFORM_DIR)/config.py),\
  $(eval export $(subst __SPACE__, ,$(line))))

This is identical to how defaults.py is consumed at variables.mk:48.

Why not port variables.mk too?

variables.mk computes tool paths (OPENROAD_EXE, YOSYS_EXE,
KLAYOUT_CMD), derived output paths (LOG_DIR, RESULTS_DIR), macro
wrappers (WRAPPED_LEFS), stream system selection (GDS vs OAS), and
Make debugging introspection. All of this is Make-flow plumbing that
bazel-orfs replaces with Bazel-native equivalents. The only shared
concern between Make and bazel-orfs consumers is the platform config
variables, which config.py now provides.

Platform migration complexity

Platform	Lines	Key constructs
nangate45	109	$(sort $(wildcard ...)) for GDS
sky130hs	108	$(PLATFORM) in paths
sky130hd	154	Long DONT_USE_CELLS += list
gf180	149	TRACK/METAL/KVALUE params, corner indirection, $(abspath)
ihp-sg13g2	182	FOOTPRINT_TCL conditional, $(shell sed) SDC parsing, $(origin)
asap7	217	VT variant templates, $(foreach)/$(eval) loop, $(addsuffix), CLUSTER_FLOPS

Reference

Plan E: https://github.com/The-OpenROAD-Project/bazel-orfs/blob/main/docs/plans/drop-make-dependency.md