Fix 5205: Handle ConcurrentModification and NPE from opening dialogs while Roun…

[Sleet01]

…d Report being handled

This should clear up some of the Exceptions reported by CasualJoker, and avoid those Exceptions breaking the game and/or sidelining Princess.

Root cause is that we are doing some weird manual tracking of open dialogs within the ClientGUI, which exposes us to ConcurrentModificationExceptions in the UI itself. These, if not handled, will propagate and break the game.
If caught, they don't cause any harm because we're removing unneeded dialogs from our list of elements, and then trying to notify the deleted dialog of the event signaling the completion of its work (usually, reinforcing from a MUL).

This fix also puts a try/catch around the contents of WAA.toDisplayableString() to avoid the case where it throws an NPE because the client instance can't dereference some information about the current target, likely due to the above bug (or because the main thread is in the context of another dialog while also trying to update the chat box or Round Report). Either way, this shouldn't break the game.

Testing:

• Ran all 3 projects' unit tests.
• Followed same steps observed in CasualJoker's game when the reported Exceptions occurred.
• Observed Princess-vs-Princess fight for many turns following reinforcing from MUL or RAT generator, which previously would throw one of the above Exceptions and then have one or another Princess instance hang.

Close #5205
Close MegaMek/mekhq#3879

[SJuliez]

I'm not sure about these changes.

[SJuliez]

This will certainly prevent an NPE here. I'm still dubious. Won't it just crash later when it tries to find the target or the weapon? If this is only called from the boardview to display some info and we definitely want to prevent exceptions for display info then I'd put the try block in boardview.

[Sleet01]

As far as I can tell, this NPE path only occurs while we're updating the Chat window and get interrupted by, for instance, the ConcurrentMod exception above. This method appears to only be called from AccessibilityWindow, so as long as we output some string it should be fine.

That said, I can make it work more like the version in AbstractAttackAction.java:

        final Targetable target = getTarget(client.getGame());
        return (target == null) ? "Attacking Null Target with id " + getTargetId()
                : "Attacking " + target.getDisplayName();

so at least the target's ID gets printed.

[kuronekochomusuke]

#3994