OMFSEGDG fails to recognize FIXUP to PUBDEF symbol that is not part of DGROUP

[joncampbell123]

Test case found:

Compiling the hw/isapnp project in tiny model initially failed because the devnode_raw array was declared far.

Watcom C generates OMF records putting it into it's own segment. That segment is NOT part of DGROUP. But that is not obvious from the FIXUP record.

LNAMES (from 11): [11]: "test13_DATA" [12]: "FAR_DATA"
OMF record type=0x98 (SEGDEF: Segment Definition Record) length=6 offset=755 blocksize=0
SEGDEF (5):
    Alignment=PARA(3) combination=PRIVATE(0) big=0 frame=16 offset=0 use0
    Length=4096 name="test13_DATA"(11) class="FAR_DATA"(12) overlay=""(1)

..

FIXUPP[95]:
    seg-relative location=16BIT-SEGBASE(2) frame_method=by-TARGET(5)
    target_method="EXTDEF"(2) target_index="_devnode_raw"(11) data_rec_ofs=0x5F(95)
    target_displacement=0 ledata_rec_ofs=0x1539(5433)+3 absrecofs=0x18F(399)

..

OMF record type=0xb6 (LPUBDEF: Local Public Names Definition Record) length=18 offset=14413 blocksize=0
PUBDEF (2):
    [2] "_devnode_raw" group=""(0) segment="test13_DATA"(5) offset=0x0(0) typeindex=0 LOCAL

The tool currently assumes all EXTDEFs are in the same DGROUP. Here is a case where an EXTDEF refers to a PUBDEF (publicly defined symbol). OMFSEGDG already gathers symbols in the first pass, so it has the ability in the second pass to determine where the symbol is and whether or not it is part of DGROUP.

[joncampbell123]

A related bug has cropped up where more than one DATA segment results in an OMF file that only carries the first data segment, resulting in an invalid file.