refactor: use store for dialog state in CardFooterInstanceActionButtons

[pownkel]

Details

Use store state instead of component state to determine when the issue filing settings dialog is open

Motivation

We should avoid using component state where possible, because it can lead to tightly coupled components if we decide to split up a file. In this case, we currently need to pass callbacks to CardFooterMenuItemsBuilder to set the state of CardFooterInstanceActionButtons, which is a confusing flow of data and doesn't fit the flux paradigm.

Instead of a background store, this PR creates a view-side CardsViewStore with the same pattern as TabStopsViewStore, which will reset its state when the page is refreshed so the dialog doesn't stay open between refreshes.

Context

Continues a change from #5852. CardFooterInstanceActionButtons is not currently used anywhere in the UI, but will be wired up in a future PR.

We currently have another dialog, the Export Report dialog, which is controlled by component state instead of store state. We may want to refactor that in a future PR for consistency.

Pull request checklist

• Addresses an existing issue: #0000
• Ran yarn null:autoadd
• Ran yarn fastpass
• Added/updated relevant unit test(s) (and ran yarn test)
• Verified code coverage for the changes made. Check coverage report at: <rootDir>/test-results/unit/coverage
• PR title AND final merge commit title both start with a semantic tag (fix:, chore:, feat(feature-name):, refactor:). See CONTRIBUTING.md.
• [n/a] (UI changes only) Added screenshots/GIFs to description above
• [n/a] (UI changes only) Verified usability with NVDA/JAWS

[dbjorge]

I think moving this state to the background feels reasonable in general, but I'm hesitant to make a generic sounding DialogActions/DialogActionCreator/dialog/-namespaced messages unless we actually intend to move most/all dialog state management into one central place. Particularly, I think it would feel a bit confusing to have a DialogActions that is unrelated to the most interesting dialog in the app (the target page details dialog).

My preference would be to reuse the existing IssueFilingActionCreator and IssueFilingActionMessageCreator instead of creating new Dialog-* stuff. That would also help minimize logical dependencies from common/components to the details view.

[pownkel]

Per offline discussion with @waabid, ended up refactoring this PR completely to use a new view-side store instead of a background store to keep behavior the same on refresh. This also removes all the generic-sounding Dialog- objects.

I considered using IssueFilingActionMessageCreator to trigger the open/close dialog actions, but it looks like the existing openDialog function isn't called anywhere, and it seems odd for something called a MessageCreator to have functions that invoke actions without using messages. I created a separate CardsViewController to wrap CardsViewActions instead.

[dbjorge]

I just had one comment on high-level naming/placement, the individual code changes all LGTM otherwise!

[dbjorge]

LGTM! It feels a little off maybe that the flux stuff is mingled under a components/ directory, but that's consistent with the tab stops view so it makes sense to change them together in a separate PR if we want to change that structure

[waabid]

LGTM