RFR: 8373096: JFR leak profiler: path-to-gc-roots search should be non-recursive

[Thomas Stuefe]

A customer reported a crash when producing a JFR recording with `path-to-gc-roots=true`. It was a native stack overflow that occurred during the recursive path-to-gc-root search performed in the context of PathToGcRootsOperation.

We try to avoid this by limiting the maximum search depth (DFSClosure::max_dfs_depth). That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small.

This RFE changes the algorithm to be non-recursive. 

Note that as a result of this change, the order in which oop maps are walked per oop is reversed : last oops are processed first. That should not matter for the end result, however. The search is still depth-first.

Note that after this patch, we could easily remove the max_depth limitation altogether. I left it in however since this was not the scope of this RFE.

Testing:

- Tested manually with very small (256K) thread stack size for the VMThread - the patched version works where the old version crashes out
- Compared JFR recordings from both an unpatched version (with a large enough VMThread stack size) and a patched version; made sure that the content of "Old Object Sample" was identical
- Ran locally all jtreg tests in jdk/jfr
- GHAs

-------------

Commit messages:
 - remove test output
 - Copyright
 - start

Changes: https://git.openjdk.org/jdk/pull/28659/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28659&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373096
  Stats: 70 lines in 2 files changed: 40 ins; 17 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28659.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28659/head:pull/28659

PR: https://git.openjdk.org/jdk/pull/28659