Use resource's `status.conversion.source` to remove redundant API fallback pattern in dashboard

The dashboard's frontend is currently using a ["unified" API](https://github.com/grafana/grafana/blob/main/public/app/features/dashboard/api/UnifiedDashboardAPI.ts) pattern to handle dashboards stored in different schema versions (v1 and v2). When a dashboard is requested through one API version and the backend cannot convert it from the stored version, the frontend catches the error and makes a second API call using the version indicated by `status.conversion.storedVersion` Since the conversion status now contains source dashboard when the conversion failed through `status.conversion.source`, we don't need to actually re-query the dashboard, but instead use the returned source directly ```ts // ConversionStatus is the status of the conversion of the dashboard. export interface ConversionStatus { // Whether from another version has failed. // If true, means that the dashboard is not valid, // and the caller should instead fetch the stored version. failed: boolean; // The error message from the conversion. // Empty if the conversion has not failed. error?: string; // The version which was stored when the dashboard was created / updated. // Fetching this version should always succeed. storedVersion?: string; // The original value map[string]any source?: any; } ``` The unified approach introduces quite some complexity to the entire system. It also causes a problem with Grafana deployments that introduce dashboard API proxy between Grafana client and serve - it require the proxy to implement all supported versions of the API, while witht the conversion status data we can at least limit the impact. My suggestion is that we investigate an alternative approach where we properly utilise the returned status data, and avoid unnecessary network round-trips.