Add sentry_dashboard_panel, resolving panels as their own resource

The open design question named in the last three commits' README --
"a sentry_dashboard_panel resource (or a panels list block on this one)"
-- is resolved: separate resource, matching api/dashboards.Handler's own
shape (a panel is created/updated/deleted independently of its parent
dashboard via its own endpoints, never by rewriting the dashboard's
whole panel list). A nested list block would have forced every panel to
be rewritten on any single panel's change, hiding fine-grained diffs a
separate resource shows naturally -- the more idiomatic Terraform
pattern for independently-lifecycled child resources, and the one that
matches what the API actually does.

Unlike sentry_alert_rule/sentry_notification_target, this resource
supports a real in-place Update -- api/dashboards.Handler actually has a
PUT /dashboards/{id}/panels/{panelId}. Only dashboard_id forces
RequiresReplace: UpdatePanel's SQL matches WHERE id = $panelID AND
dashboard_id = $dashboardID, so changing dashboard_id through the
existing panel's URL wouldn't move it, it would just fail to match --
there's no API operation for "move a panel to a different dashboard."

Panels have no standalone GET endpoint -- only GET /dashboards/{id},
which includes the full panels array. client.go's new getPanel fetches
the parent dashboard and finds the panel by ID within it, returning the
same *apiError{StatusCode: 404} shape a direct GET would whether the
dashboard itself or just the panel within it is gone, so isNotFound
works identically either way. This also means a bare panel ID isn't
enough to import from -- ImportState takes "dashboard_id/panel_id" and
splits on the last "/", the one resource here with a composite import
identifier.

query_language never accepts "sql" for panels specifically -- confirmed
in api/dashboards's own validatePanel ("dashboards only support
pipe-syntax queries, since the dashboard time-range picker is injected
as leading query terms"), a real constraint from the API this client
doesn't re-validate client-side (same "let the API be the one source of
truth for validation" posture the other resources already take), but
documented in the schema so it's not a surprise 400 from Create.

sentry_dashboard_panel gets a matching data source too
(dashboard_id + id both Required, unlike the other three data sources'
single Required id, since getPanel itself needs both).

Verified: client tests are real httptest.Server round trips, including
getPanel finding the right panel within a real dashboard response and
returning a recognizable not-found both when the panel is missing and
when the parent dashboard itself is gone. Schema validation needs no
Terraform binary. TestAccDashboardPanelResource_basic and
TestAccDashboardPanelDataSource_basic are real acceptance tests,
skip-gated by TF_ACC same as the other six -- the resource test proves a
genuine in-place update (a title change, no plancheck needed since
in-place update is the default expectation here, unlike the
create/destroy-only resources). Not run against a live stack in this
environment, same disclosed gap as everything else Docker-gated in this
repo.

terraform/examples/resources/sentry_dashboard_panel/import.sh

@@ -0,0 +1,4 @@
+# "dashboard_id/panel_id" -- a bare panel id isn't enough to import
+# from, since Read needs the parent dashboard_id to know where to look
+# (there's no standalone GET for a single panel).
+terraform import sentry_dashboard_panel.error_rate <dashboard-id>/<panel-id>

terraform/examples/resources/sentry_dashboard_panel/resource.tf

@@ -0,0 +1,20 @@
+resource "sentry_dashboard" "checkout_errors" {
+  name = "Checkout Errors"
+}
+
+resource "sentry_dashboard_panel" "error_rate" {
+  dashboard_id = sentry_dashboard.checkout_errors.id
+  title        = "5xx rate over time"
+  query        = "service=checkout status>=500 | timechart count"
+  viz_type     = "line"
+  position_x   = 0
+  position_y   = 0
+  width        = 6
+  height       = 4
+}
+
+# Unlike sentry_alert_rule/sentry_notification_target, this resource
+# supports a real in-place update -- api/dashboards.Handler has a real
+# PUT /dashboards/{id}/panels/{panelId}. Only dashboard_id forces a
+# destroy-and-recreate (there's no API operation to move a panel between
+# dashboards).