librevdep: add opt-in called-supplied LD_LIBRARY_PATH emulation

[sighook]

Problem

librevdep intentionally avoids environment-dependent resolution, and revdep_semantics(7) currently lists LD_LIBRARY_PATH as a non-goal.
However, some embedding use-cases may want to audit "would this object resolve under a supplied runtime library path?".

This should not be implemented by reading the process environment inside the library. That would make results implicit, host-coupled, and contrary to the current explicit-context design.

Target

Add optional explicit emulation of LD_LIBRARY_PATH via caller-supplied directories.

Non-goal

Do not read ambient process environment (getenv("LD_LIBRARY_PATH")) inside librevdep.

Suggested shape

• Add process_search_dirs/runtime_library_path to context or per-audit options
• Search these dirs at the loader-equivalent point in the order
• Keep default behavior unchanged when the field is empty
• Optionally add a boolean to model secure-exec suppression

Acceptance criteria

• Results depend only on explicit inputs
• No hidden environment dependency is introduced
• Users can emulate LD_LIBRARY_PATH when they need that analysis mode

[sighook]

As written in our docs, LD_LIBRARY_PATH is currently a non-goal because it is process-specific state. That is coherent with the library's current architecture: explicit context, no hidden global memory, no dependence on environment state.

It's important to ensure that "support LD_LIBRARY_PATH" does not mean "read getenv() from inside the library". That would make the semantics implicit, host-coupled, and awkward in parallel/embedded use. The loader does search LD_LIBRARY_PATH before DT_RUNPATH, unless secure-exec disables it. ld.so(8) recommendation: Do not implement ambient-environment reading.

P.S. Perhaps, we should rename that issue into "revdep_semantics: keep LD_LIBRARY_PATH out of scope for deterministic static audit", since that's more a policy decision than feature request.