Store warning state with some deferred actions

[ISSOtm]

For example, compare:

opt -Wassert
def x = 0
pusho -Wno-assert
assert warn, x, "🗣️"
popo
; Does not warn.

and

opt -Wassert
pusho -Wno-assert
assert warn, x, "🗣️"
popo
def x = 0
; Warns!

(There's also, possibly, an inconsistency between whether rgbasm -Wno-assert but rgblink -Wassert should warn about those assertion failures.)

I think this issue applies not just to assertions, but generalises to any “deferred” warnings, which can also occur from some link-time expressions. There's no way to silence a specific file's warnings, in particular; we may know that one specific warning is spurious (possibly it's in a dependency we do not wish to patch), but still want to be warned about others.

[Rangi42]

Makes sense to me. The only warnings that can be deferred are the "shared" ones which exist in both RGBASM and RGBLINK, right? That would be:

• -Wassert: for assertions
• -Wdiv: for / dividing -2³¹ by -1 in RPN expressions
• -Wobsolete: for obsolete syntax... although there currently is none in RGBLINK
• -Wshift: for >> right shifting a negative value
• -Wshift-amount: for <</>>/>>> shifting by an amount outside [0, 32)
• -Wtruncation: for when implicit truncation loses some bits

If it were just -Wassert, we could reasonably update the object file format to attach the current -Wassert state to each emitted assertion, since the fraction of assertions in a whole object should be low. But most of those warnings apply to RPN expressions, and it would not be reasonably cheap to attach all of their states to every RPN.

So instead, we might be able to track the list of all unique warning combinations seen (just for those shared six, of course), and for each deferred assertion and RPN expression, attach a single 32-bit index into that list. And of course output the list itself in the object file.

Some concerns:

• Even if we're only outputting those six warning states in the object file, the format should be extensible to handle any new warnings.
• The identifiers for these warnings would now be guaranteed as part of the object file spec, and shared by RGBASM and RGBLINK. We could use strings, but we'd probably still want t associate numeric indexes with them for cheaper references. We probably don't want to make the WARNING_* enums themselves a guaranteed property, it would be annoying to keep a shared subset of both programs' WARNING_*s in sync.
• Tracking the warning state means tracking the whole state (meta and specific). For example, if RGBASM has OPT -Wno-everything and RGBLINK has -Wdiv, the specific enablement overrides the meta disablement.

No matter how we do this, it would have to be a breaking object file change.