Sync vulnerability report state with querystring

Summary

On the vulnerability report, there are 2 tabs:

The querystring and vulnerability report state should sync in the following manner:

1. When loading the page for the first time or when using the browser's forward/back buttons, the state should sync from the querystring to the report. The state should only be synced to the currently-selected tab, i.e. if the querystring has ?tab=operational, the state should be restored for only the operational tab, but not the development tab. The development tab should have the default state as if there was no querystring.

2. When the filters, page, column sort, selected tab, and/or page size is changed, the state should sync from the report to the querystring.

3. Changing tabs should keep the report state for that tab. In other words, if the user changes a bunch of stuff on one tab, then switches to the other tab and changes a bunch of stuff there, if they toggle between the tabs the state should be the same as before.

Implementation details

We need to sync the entire state of the vulnerability report, which includes the selected tab, filters, current page (before and after querystring), column sort and direction, and maybe also the page size selector (may be non-trivial because it saves/restores from localstorage rather than the querystring).

This will require reworking the filters and how the vulnerability report processes the state. The challenge is that we need to send data in a certain format for the GraphQL query, and we also need to save something to the querystring, but the two are different in some cases. For example, the activity filter saves ?activity=WITH_ISSUES to the querystring, but it sends { hasIssues: true hasResolution: false } to GraphQL, so we will need to be able to translate the querystring state to GraphQL variables.

Additionally, the vulnerability report is used with tabs in some places (project, group, and instance reports), and without tabs (single report only) in other places (pipeline security tab and agent report). The sync will need to support both workflows.

We also need to sync the state of the currently-active tab only. For example, if the user changes 3 filters on one tab, then switches tabs and changes 2 filters, the querystring should only have the state of 2 changed filters. In other words, when the user changes tabs, we need to "reset" the querystring and the sync the state of the new tab, rather than keeping any state from the previous tab.

Lastly, if at all possible we should keep this logic in one place. Currently, each filter, sort, selected tab, current page, and page size are different components at different places in the component tree that individually handle each its own querystring save/restore. Now that we need to sync the entire state of the report, we should collate the logic together into one place so that we can save/restore as a single operation rather than try and handle it in each component individually.