Don't display multiple errors on the main WordPress dashboard

## Bug Description

If a server is performing slow an error message can appear that you're offline within the main Site Kit dashboard, within the module widgets.

If this occurs on the main WordPress dashboard, within the Site Kit widget, these notices are stacked, as per the screenshot below.


If possible (should the retry button refresh all data, and not just Analytics or SC data), display only one such error with the retry button.

## Steps to reproduce

1. Install a plugin that disables the WP REST API. In my case I used the [Disable REST API plugin.](https://wordpress.org/plugins/disable-json-api/)
2. Ensure the REST API is blocked for administrators (if using the same plugin "_Settings > Disable REST API > Administrator > toggle off the SK endpoints_" - [screenshot](https://i.imgur.com/KKsXiw7.png))
3. Visit your main WP dashboard, where the error appears in multiple notices. If the error doesn't appear, wait an hour, or clear your session storage in order for cached responses to expire

## Screenshots

## Additional Context

- PHP Version:
- OS: [e.g. iOS]
- Browser: [e.g. chrome, safari]
- Plugin Version: [e.g. 22]
- Device: [e.g. iPhone6]

---------------

_Do not alter or remove anything below. The following sections will be managed by moderators only._

## Acceptance criteria

* The display of error messages on Site Kit WP Dashboard widget should be consolidated in the following way:
* Errors from same module should be deduplicated - only one error message should be displayed per error per module.
* Retrying an error should retry all the underlying sources that were consolidated into that error.

## Implementation Brief

* In current case, each widget returns the error(s) from state separately. Solution is to show errors in more centralised way in main widget component - `assets/js/components/wp-dashboard/WPDashboardWidgets.js`.
* So in that file fetch errors from following module stores: `MODULES_SEARCH_CONSOLE`, `MODULES_ANALYTICS_4`, `MODULES_ANALYTICS`. Creating separate variables that will hold the errors from the state associated with these modules, like `searchConsoleErrors`, `analytics4Errors` and `analyticsErrors`, each would fetch associated error from it's store, like this - https://github.com/google/site-kit-wp/blob/954d8ddd1fa01e09e87a51f8a0e7805d9310f2b6/assets/js/components/wp-dashboard/WPDashboardImpressions.js#L64-L68
* Then include the `ReportError` component from `assets/js/components/ReportError.js`
* If there is an error originating in one these modules, like `MODULES_ANALYTICS_4` for example, it will always be rendered in all it's widgets, due to individual check in these widgets. That way we can use the appropriate error variables to check against errors before we render these widgets, so we can render one `ReportError` component with consolidated messages, instead of each widget with same error message. For `searchConsoleErrors` use it to conditionally render search console widgets - https://github.com/google/site-kit-wp/blob/954d8ddd1fa01e09e87a51f8a0e7805d9310f2b6/assets/js/components/wp-dashboard/WPDashboardWidgets.js#L137-L138 , like:
```jsx
( searchConsoleErrors ?
:




)
```
* Since analytics and analytics4 widgets are spread above and bellow search console widgets, add only `analytics4Errors` and `analyticsErrors` conditional rendering for `ReportError` before first widgets - https://github.com/google/site-kit-wp/blob/954d8ddd1fa01e09e87a51f8a0e7805d9310f2b6/assets/js/components/wp-dashboard/WPDashboardWidgets.js#L122-L135
* And for all analytics and analytics4 widgets, add one more condition for rendering - if there is no error, like this:
```jsx
{ ( analyticsModuleActiveAndConnected && ! analyticsErrors ) &&
isGA4DashboardView === false && (




) }

{ ( isGA4DashboardView && ! analytics4Errors ) && (




) }
```
* Do the same for first two analytics and analytics4 widgets
* `ReportError` component accepts array of errors, it will take care of consolidating the error messages within one error components, and `ReportErrorActions` component inside that handles the Retry action, will handle all underlying sources that were consolidated into that error.

### Test Coverage

* update any failing VRT images

## QA Brief

*

## Changelog entry

*

Start in assets/js/components/wp-dashboard/WPDashboardWidgets.js and read how module errors and widgets are currently rendered. Check assets/js/components/ReportError.js and the referenced module store selectors, then run the relevant visual regression tests. Done means duplicate module errors are consolidated into one message and retrying it retries all underlying sources; update any failing VRT images.

Written by the indexing model from the issue text.