RFR: 8334866: Improve Speed of ElfDecoder source search [v5]

[Kerem Kat]

> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
> 
> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
> 
> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.

Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge branch 'master' into elfdecoder-JDK-8334866
 - fix DWARF_LOG_INFO
 - Comment on ArangesCache
 - Fix secondary sort order and comment
 - Remove move ctor of ArangesCache
 - Clarify when we can fallback to linear scan, which doesn't seem to allocate on the heap
 - Move ArangesCache into DebugAranges, and DebugAranges into DwarfFile
 - inline sort
 - goto considered harmful
 - Use QuickSort::sort instead of qsort
 - ... and 5 more: https://git.openjdk.org/jdk/compare/9c486911...ae72cae8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27337/files
  - new: https://git.openjdk.org/jdk/pull/27337/files/623870ee..ae72cae8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=03-04

  Stats: 12293 lines in 221 files changed: 7778 ins; 3047 del; 1468 mod
  Patch: https://git.openjdk.org/jdk/pull/27337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27337/head:pull/27337

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