Add extended-analysis=local to bound data-flow memory on large source trees

[carlfriedrich]

Summary

Adds a third value, local, to the existing extended-analysis option (flag, .shellcheckrc, and inline directive). It runs dataflow analysis per file, treating source'd files as opaque boundaries instead of inlining their bodies into the control-flow graph.

extended-analysis becomes a three-way scope control:

Value	Dataflow analysis	Sourced files
true (default)	whole-program	inlined into the control-flow graph (data flow followed across source)
local (new)	per file	opaque boundary (defined functions/vars treated as unknown at the call site)
false	none	(n/a)

All three still follow sources for parsing and AST-level checks (variable resolution, SC2154, etc.), they differ only in how far the data-flow pass reaches.

true/false are unchanged and fully backward compatible.

Motivation

ShellCheck's whole-program iterative dataflow analysis can consume a great deal of memory on large graphs. The worst case is a set of scripts that each source a shared tree of libraries and are all checked in one invocation: every includer re-inlines the entire sourced tree into its own control-flow graph, and the context-sensitive fixpoint (which retains per-call-path state) then runs over that multiplied graph. Memory grows super-linearly with graph size.

This is the situation described in #3177 and #3442. The current escape hatch is extended-analysis=false, which throws out all dataflow checks. local is a middle ground: it keeps per-file dataflow analysis (so intra-file checks such as SC2317 still fire) while removing the cross-file multiplication that drives the blow-up.

What changes for users

• New value: --extended-analysis=local, extended-analysis=local in .shellcheckrc, and # shellcheck extended-analysis=local inline.
• local keeps dataflow checks that are decidable within a single file.
• local gives up dataflow that crosses a source boundary. Concretely, it won't use knowledge from a sourced file (e.g. "this sourced function always exits", "this sourced variable is always an integer") the way true does. Compared to true this can mean a few fewer/extra findings around cross-source data flow. Compared to false it is strictly more analysis.

Evidence

A real ~200-file project (many scripts sourcing files from a shared library tree), whole-tree invocation:

Mode	Peak RSS	Findings
true	2031 MiB	85
local	834 MiB	81
false	387 MiB	80

On that project local roughly halves peak memory versus true. The 4-finding delta is cross-source dataflow that true resolves via inlining.

Review note / open question

I chose local as a new additional value (single lowercase word, matching existing directive-value conventions) to keep the change minimal. A fully-named triad would probably be more consistent, though (e.g. none/local/full with true/false kept as backwards-compatible aliases). Open for discussion.