dso3.c: Investigate operator precedence ambiguity in fwim_ object matching

[justwheel]

Summary

Clang flags an operator precedence ambiguity in dso3.c:109 where == binds more tightly than &, potentially diverging from the original FORTRAN intent.

Background

The CI pipeline introduced in PR #38 revealed a -Wparentheses warning from Clang in dso3.c line 109, inside the fwim_ function.
The expression ~ (nocare) & (objcts_1.oflag1[i - 1] & TAKEBT) == 0 is evaluated by C as ~nocare & ((oflag1 & TAKEBT) == 0) because == has higher precedence than &.
If the original FORTRAN intended (~nocare & (oflag1 & TAKEBT)) == 0, then this is a latent logic bug introduced during the f2c translation.
However, the game has shipped with this code for over 30 years without reported issues, so the expression may be correct by coincidence or the affected code path may be rarely triggered.

Details

1. Locate the original FORTRAN source for the FWIM function to determine the intended grouping of the IAND / .EQ. operations.
2. Determine whether the C precedence produces the same result as the FORTRAN semantics for all possible values of nocare and TAKEBT.
3. If the behavior diverges, add explicit parentheses to match the FORTRAN intent.
4. If the behavior is coincidentally correct, add explicit parentheses anyway to silence the warning and document the intent.

This can be fixed as part of v1.1.0, but will most likely be addressed in a future release to help get recent changes submitted downstream in the Fedora package.

Outcome

The fwim_ object-matching logic is verified against the original FORTRAN source and parenthesized to remove the ambiguity and silence the Clang -Wparentheses warning.