perspective-workspace: safer isVisible() callbacks

[tomjakubowski]

I've been seeing "cannot read properties of null" errors in these isVisible() callbacks while developing a React application which wraps <perspective-workspace>. The error message details suggest getWidgetByName() is returning null at some point.

Make these isVisible() callbacks safer with the null coalescing operator, to avoid null 'dereferences' when getWidgetByName() returns null. In this case, the command is considered not visible.

I didn't pin down reliable repro steps. Although from a look at this code's context, it might be related to a viewer widget being deleted from the workspace, or perhaps the viewer being renamed, while at the same time Lumino is rendering workspace commands (such as in the context menu).

Pull Request Checklist

• Description which clearly states what problems the PR solves.
• Description contains a link to the Github Issue, and any relevent
  Discussions, this PR applies to.
• Include new tests that fail without this PR but passes with it.
• Include any relevent Documentation changes related to this change.
• Verify all commits have been signed in accordance with the DCO policy.
• Reviewed PR commit history to remove unnecessary changes.
• Make sure your PR passes build, test and lint steps completely.

[texodus]

Thanks for the PR!

@perspective-dev/workspace is actively being overhauled in #3044, specifically to add dedicated React support as both a physical component and API + behavior fixes in the existing custom element (as we also did for @perspective-dev/viewer in #2893). Ergo, I am going to close this PR since its not going to be merged independently.

@timbess can cherry-pick this change into #3044, but given the amount of work we're putting in to trying to fix workspace so it does not have internal issues like this that need to be suppressed, I feel like the tests have at least equal value here.

Although from a look at this code's context, it might be related to a viewer widget being deleted from the workspace, or perhaps the viewer being renamed, while at the same time Lumino is rendering workspace commands (such as in the context menu).

We should start by adding tests for these cases for sure. Neither viewer widget deletion nor renaming have tests, and there are multiple independent methods by which these actions may occur (By calling restore() without this viewer specified or with a modified name? By removing the custom element in the DOM? By calling its' delete() method?).