[llvm] [BOLT][DWARF] Skip processing DWO files with ID 0 (PR #154749)

[Jinjie Huang via llvm-commits]

Jinjie-Huang wrote:

@ayermolo Thanks for the review. 

This kind of dwarf can reproduced  via thinlto + split-dwarf + "-fsplit-dwarf-inlining" with clang prior to this [commit](https://github.com/llvm/llvm-project/commit/e731a2678c7cf81b1d3817489a52b519cb14f85e).
And we can get dwarf like this(btw,  a test has also been added):
```
0x000000d7: Compile Unit: length = 0x00000025, format = DWARF32, version = 0x0005, unit_type = DW_UT_skeleton, abbr_offset = 0x005b, addr_size = 0x08, DWO_id = 0x0000000000000000 (next unit at 0x00000100)

0x000000eb: DW_TAG_skeleton_unit
              DW_AT_stmt_list [DW_FORM_sec_offset]	(0x000001f3)
              DW_AT_str_offsets_base [DW_FORM_sec_offset]	(0x00000008)
              DW_AT_comp_dir [DW_FORM_strx1]	(".")
              DW_AT_GNU_pubnames [DW_FORM_flag_present]	(true)
              DW_AT_producer [DW_FORM_strx1]	("clang version 16.0.6 (gitlab at git.byted.org:sys/llvm-project.git ae0ef36eb8428ef48cb345a0e0c9ad6b3f289590)")
              DW_AT_language [DW_FORM_data2]	(DW_LANG_C_plus_plus_14)
              DW_AT_name [DW_FORM_strx1]	("callee.cpp")
              DW_AT_addr_base [DW_FORM_sec_offset]	(0x00000008)

0x000000fd:   DW_TAG_subprogram
                DW_AT_name [DW_FORM_strx1]	("hotFunction")
                DW_AT_inline [DW_FORM_implicit_const]	(DW_INL_inlined)
```
The compiler generates DWARF for the cross-CU callee source file, and there can be multiple CUs with a dwoid of 0. This DWARF seems  structurally normal, except that the dwoid is left at its initial value of '0'. I’m not sure whether this counts as a 'broken DWARF', or whether it can be effectively detected.

The current implementation of this patch skips processing duplicates with a dwoid of 0, is this reasonable?


https://github.com/llvm/llvm-project/pull/154749