Add OBOM: IAM access graph extraction from IaC (--include-obom)

[jthDEV]

Summary

Adds --include-obom to ts-scan scan: extracts an OBOM (Ownership Bill of
Materials — an IAM access graph, {principal, resource, actions[], effect, grantedVia}) from any CloudFormation/SAM or Terraform found in the local
scan sources.

This is evidence ts-tm-agent
currently has none of for its threat-model trust-boundary work — today its
trust zones are inferred from SBOM/dependency signals alone. Full background
in src/ts_scan/analyse/obom.py's module docstring.

Why a vendored subset instead of a checkov dependency

pip install checkov directly conflicts with ts-scan's own pins on three
libraries — importlib-metadata, cyclonedx-python-lib, packageurl-python
— the latter two core to ts-scan's own SBOM/PURL generation. Investigated
whether checkov's full dependency footprint (~50 packages: boto3,
cloudsplaining, detect_secrets, aiohttp, policy_sentry, …) was actually
needed for graph-building specifically — it wasn't. All of it turned out to
be pulled in through unused import couplings (e.g. cfn_utils.py imports
checkov's entire IAM check registry just for one unrelated function's unused
default-parameter value; graph-building never calls that function).

analyse/_obom_vendor/checkov/ is a trimmed, patched copy (Apache-2.0,
NOTICE.md documents provenance and every change made) containing only the
~25 files graph-building genuinely needs, plus 23 stub modules (a
unittest.mock.MagicMock behind a module-level __getattr__) replacing
subsystems that are imported on that path but never called. One real code
change: common/util/json_utils.py's CustomJSONEncoder is genuinely used
(Terraform variable serialization) and got local unreachable sentinel classes
for four cross-subsystem isinstance() branches instead of a blanket stub.

Resulting new dependencies (the obom extra): bc-python-hcl2,
bc-jsonpath-ng, networkx, dpath, asteval — none conflict with
ts-scan's existing pins.

Verification

• Output verified byte-identical to a real (non-vendored, non-trimmed)
  checkov-backed extraction, against two fixtures: a real-world SAM template
  (CloudFormation: 15 edges / 3 unresolved) and a hand-written Terraform
  fixture using a different structural IAM pattern (1 edge / 1 unresolved) —
  both before and after trimming, and again through the actual installed
  ts-scan[obom] package and the --include-obom CLI flag end to end.
• Regression: existing test suite (26 tests) passes unchanged; a plain
  ts-scan scan run (no --include-obom) produces identical output to
  before this change.

Design notes / open questions for review

• --include-obom runs as an independent second pass, not folded into the
  dependency-scan output — IaC isn't tied to a specific package-manager
  DependencyScan, so OBOM is its own JSON artifact (--obom-output,
  defaults to alongside --output or stdout) rather than a new field on the
  existing scan format. Open to a different shape if there's a preference.
• Only local Path sources are examined for OBOM; a file:// URL source in
  sources is not resolved back to a path for this pass.
• CloudFormation/SAM and Terraform only for now (Terraform confirmed to
  reuse the same trimming approach cleanly — same checkov.*.graph_manager
  abstraction). Other checkov-supported IaC front-ends (Kubernetes, ARM,
  Bicep, Dockerfile) not attempted.
• The vendored subset needs a manual re-trim if checkov's graph-builder
  internals change upstream in a way that breaks it — process documented in
  _obom_vendor/NOTICE.md.

Test plan

• pip install -e ".[obom]" resolves cleanly
• ts-scan scan --include-obom <dir-with-sam-template> — matches known-good edge/unresolved counts
• ts-scan scan --include-obom <dir-with-terraform> — matches known-good edge/unresolved counts
• ts-scan scan <dir> (no flag) — output unchanged from before this PR
• pytest tests/ — 26/26 pass

[gr-markin]

I wouldn't merge the OBOM functionality in this form into the ts-scan repo, first of all it's a massive amount of code, approx. 300 files alone for OBOM analysis that doesn't have anything in common with the "ts-scan", I would suggest to move everything belonging to OBOM to a separate repo and publish it as a separate Python package. If is's really required to have a flag in the ts-scan, then the ts-scan[obom] option should require this package and make a call into it, but again, I don't see any reason to integrate it into the ts-scan as it's completely distinct from the input as well as from the output, i.e. in order to apply an OBOM scan I need to install an extra option and use an extra flag, so, I could actually install a "ts-obom" package and do "ts-obom scan"