feat(spec): add providers repository split specification

[marcusburghardt]

Summary

Add specification 004 for migrating the OpenSCAP and AMPEL provider implementations out of the complyctl repository and into the standalone complytime-providers repository.

The spec defines the full scope of the migration:

• Provider relocation: cmd/openscap-plugin/ and cmd/ampel-plugin/ move to complytime-providers as a monorepo with a single root go.mod.
• Terminology rename: All uses of "plugin" referring to the extensibility mechanism are replaced with "provider" across Go identifiers, CLI output, documentation, CI workflows, and the Makefile — with explicit carve-outs for the hashicorp/go-plugin library name and the proto package (complyctl.plugin.v1, deferred to a future major version).
• SDK rename: pkg/plugin/ is renamed to pkg/provider/; all internal import paths updated.
• CI updates: ci_compliance.yml is updated to download the complyctl-provider-ampel binary from complytime-providers release artifacts instead of building it from source.
• Development sequencing: complytime-providers may use a temporary replace directive during development; it must be replaced with a published versioned reference before merging.

RPM spec and testing-farm / Packit configuration updates are explicitly out of scope and will be addressed in a follow-up specification.

Related Issues

• Separate ampel and openscap plugins #447

Review Hints

• This PR contains only the specification (specs/004-providers-repository-split/spec.md) and its quality checklist (checklists/requirements.md). No source code changes are included.

• Risks to consider when reviewing:

  • The pkg/plugin/ → pkg/provider/ rename changes the published Go import path for the provider SDK. Any external consumer importing github.com/complytime/complyctl/pkg/plugin will break — this must be coordinated with a tagged complyctl release that providers consume via a versioned require statement.
  • The handshake wire values ("COMPLYCTL_PLUGIN" magic cookie and UUID) are preserved byte-for-byte. Only Go identifier names change. Verify this distinction is clearly understood before implementation begins, as getting it wrong silently breaks all provider connections at runtime.
  • The ci_compliance.yml daily workflow has a new hard dependency on complytime-providers publishing release artifacts. If complytime-providers has no release yet when the complyctl CI is updated, the daily compliance check will fail. The sequencing assumption (providers repo publishes a release first) should be validated before implementation.

• Improvements unlocked after migration:

  • Core complyctl CI runs become faster and cheaper — no more building or testing provider source on every core PR.
  • Provider authors gain a dedicated, focused repository with its own CI, issues, and release cadence, removing the need to navigate core complyctl internals.
  • New providers can be added to complytime-providers without any changes to the complyctl repository, eliminating cross-repo PR dependencies for provider lifecycle events.
  • The complytime-providers monorepo layout makes it trivial to add a third provider in the future — just a new cmd/<name>/ directory under the existing go.mod.

• Flexibility for follow-up changes:

  • The proto package rename (complyctl.plugin.v1 → complyctl.provider.v1) is explicitly deferred. The spec documents the rationale (wire compatibility) and leaves a clean decision record for a future major version bump.
  • RPM and testing-farm configuration are deferred to a separate spec, keeping this change atomic and reviewable on its own merits.
  • The monorepo layout in complytime-providers does not preclude splitting providers into separate modules later — the single go.mod is a starting point, not a permanent constraint.

[jpower432]

LGTM. Left two nits.