This is a refactor with a few incidental user-facing changes (eg not showing a sometimes-incorrect total count in the UI).

Make usePageSwitcherPagination and useShowMorePaginationUrl support storing filter and query params, not just pagination params, in the URL. This is commonly desired behavior, and there are many ways we do it across the codebase. This attempts to standardize how it's done. It does not update all places this is done to standardize them yet.

Previously, you could use the options: { useURL: true} arg to usePageSwitcherPagination and useShowMorePaginationUrl. This was not good because it only updated the pagination URL querystring params and not the filter params. Some places had a manual way to update the filter params, but it was incorrect (reloading the page would not get you back to the same view state) and had a lot of duplicated code. There was actually no way to have everything (filters and pagination params) updated in the URL all together, except using the deprecated <FilteredConnection>.

Now, callers that want the URL to be updated with the connection state (including pagination and filters) do:

const connectionState = useUrlSearchParamsForConnectionState(filters)
const { ... } = usePageSwitcherPagination({ query: ..., state: connectionState}) // or useShowMorePaginationUrl

Callers that do not want the connection state to be reflected in the URL can just not pass any state: value.

This PR also has some other refactors:

• remove <ConnectionSummary first> that was used in an erroneous calculation. It was only used as a hack to determine the totalCount of the connection. This is usually returned in the connection result itself and that is the only value that should be used.
• remove ?visible=N param from some connection pages, just use ?first=N. This was intended to make it so that if you reloaded or navigated directly to a page that had a list, subsequently fetching the next page would only get pageSize additional records (eg 20), not first (which is however many records were already showing) for batch-based navigation. This is not worth the additional complexity that ?visible= introduces, and is not clearly desirable even.
• 2 other misc. ones that do not affect user-facing behavior (see commit messages)

Test plan

Visit the site admin repositories and packages pages. Ensure all filter options work and pagination works.