feat: add datasource grafana_oncall_on_call_shift

[trotttrotttrott]

This would be useful for for shifts with an until value in the past. There's no longer a need to maintain them as a resource.

Removing them from state is also an option, but you still need a reference to the ID if you want to keep it configured in your schedule. Keeping them associated with their schedules is useful for looking back in time.

The solution would be to remove old shift resources and replace them with this datasource to reduce code and keep schedule shift history in tact.

Example code:

resource "grafana_oncall_schedule" "primary" {
  name               = "OnCall Primary"
  ...
  shifts = [
    data.grafana_oncall_on_call_shift.old.id,
    grafana_oncall_on_call_shift.new.id,
  ]
}

resource "grafana_oncall_on_call_shift" "new" {
  name       = "The team"
  by_day     = ["MO", "TU", "WE", "TH", "FR"]
  week_start = "MO"

  frequency = "weekly"
  interval  = 1
  duration  = 60 * 60 * 12

  type = "rolling_users"
  rolling_users = [] # this is particularly tricky to maintain for old schedules
  start = "2025-07-14T03:00:00"
}

# much more concise, isn't so concerned if something changed...
data "grafana_oncall_on_call_shift" "old" {
  name = "The old team"
}

[github-actions]

In order to lower resource usage and have a faster runtime, PRs will not run Cloud tests automatically.
To do so, a Grafana Labs employee must trigger the cloud acceptance tests workflow manually.

[willgallego-grafana]

wonder if this is the time to start using grafana_irm_* as a prefix. It would help with the name oddity here.

[trotttrotttrott]

That would be cool 👍

shift is particularly odd. I initially implemented this as grafana_oncall_shift, but realized the corresponding resource is grafana_oncall_on_call_shift and followed suit for consistency. Not sure why the extra on_call segment. Other resource/datasource names do not have this.