[FEATURE] LogsTable: add Grafana migration script

[rickardsjp]

Description

Add a Grafana migration script (migrate.cue) for the LogsTable plugin, enabling automatic conversion of Grafana logs panels to Perses LogsTable panels via percli migrate.

The migration maps the following Grafana panel options to LogsTable spec fields:

• options.wrapLogMessage to allowWrap
• options.showTime to showTime
• options.enableLogDetails to enableDetails (defaults to true if absent)

Options without a LogsTable equivalent (showLabels, sortOrder, dedupStrategy) are not migrated.

Note

This PR covers panel migration only. Query migration for Loki targets is not included: The Prometheus query migration script currently matches any target with an expr field (including Loki targets) due to a greedy catch-all, and percli has no way to prioritize a more specific match as far as I can tell.

Screenshots

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.

[AntoineThebaud]

Thanks for your contribution!

[AntoineThebaud]

This PR covers panel migration only. Query migration for Loki targets is not included: The Prometheus query migration script currently matches any target with an expr field (including Loki targets) due to a greedy catch-all, and percli has no way to prioritize a more specific match as far as I can tell.

Could you please open a dedicated issue for this? But that's a tricky case, as precised in the PrometheusTimeSeriesQuery migration schema:

plugins/prometheus/schemas/prometheus-time-series-query/migrate/migrate.cue

Lines 17 to 20 in 6c98c0b

	// /!\ Best-effort conversion logic that may wrongly convert not-prometheus queries to PrometheusTimeSeriesQuery:
	// Ideally we should rely on datasource.type = "prometheus" to identify prometheus queries. But in some cases,
	// this information is not be available. Thus the condition relies on the presence of the "expr" field, that
	// likely indicates that this is a prometheus query.

I think the proper way to get out of this would be to check more in deep the expr field content in both plugins, to see if it describes respectively a promQL query or loki query, but that's easier said than done..