Fix --profile function timing stack leak on nextfile inside a function

[bertysentry]

Fixes #557

Problem

Under --profile, executeNextfile unwound the runtime call frames (popAllFrames + clearOperandStack) without touching activeProfilingFunctions. Every nextfile executed from inside a user-defined function therefore:

• permanently leaked a deque entry (unbounded memory growth on long profiled runs), and
• skewed the function timing report: the abandoned calls were missing from the report entirely when the program ended normally, or were "exited" at program exit with wildly wrong durations.

Fix

• resetCallState() now records exits for all active profiling functions (via the existing recordAllFunctionExits) before unwinding, mirroring what EXIT_* does, so the durations end at the point the calls are abandoned.
• executeNextfile delegates to resetCallState() instead of its inline two-line unwind. This also fixes a second leak on the same path: elementArgumentReferences was never cleared on nextfile.
• The exception abort paths, which already went through resetCallState(), now settle the profiling stack the same way, so a reused AVM cannot carry stale entries into a later run.

Notes

• The issue also names next inside a function, but Jawk currently rejects that at compile time (cannot next; not within any input rules) while gawk accepts it — that compat gap is tracked separately in next inside a user-defined function is rejected at compile time #580, and its future implementation will inherit this fix by unwinding through resetCallState().
• New test profileOptionRecordsFunctionsUnwoundByNextfile drives --profile with a nested outer() -> inner() -> nextfile chain across three input files and asserts each function is reported with exactly 3 executions. It fails on unfixed code (inner/outer missing from the report) and passes with the fix.
• User-visible profiling report change recorded under Unreleased in behavior-changes.md.

mvn verify passes (checkstyle, PMD, SpotBugs clean); the failsafe compat-suite failures are the known pre-existing ones (@load etc.), unrelated to this change.

🤖 Generated with Claude Code