feat(processor): add an option to configure validation strictness

[LMLiam]

Problem

The processor's validations are hard‑coded to Diagnostic.Kind.ERROR (fail the build). There is no way for a consumer to relax a check — e.g. to allow a class that implements a contract without @ServiceProvider during a migration, or to treat "missing provider" as a warning. A configurable strictness option would make adoption smoother.

Evidence

• Missing‑@ServiceProvider is always an ERROR (ServiceSchemeProcessor.kt:125-129).
• Non‑@ServiceContract target is always an ERROR (ServiceSchemeProcessor.kt:148-152).
• The @SupportedOptions(...) annotation is currently misused for incrementality (see the incremental‑processing issue) — there is genuinely no processor option wired up to read via processingEnv.options.

Proposed implementation

• Introduce real processor options (read from processingEnv.options), e.g. spiTooling.strict (default true) and/or per‑check toggles, and declare them in @SupportedOptions (its actual purpose).
• When relaxed, downgrade the corresponding diagnostics to WARNING.
• Wire the option through kapt (kapt { arguments { arg(...) } }) / annotationProcessorArgs / KSP options and document it.

Acceptance criteria

• A consumer can downgrade the missing‑provider / non‑contract‑target checks to warnings via a documented processor option.
• Default behavior (strict) is unchanged; tests cover both strict and relaxed modes.

---

✅ Triage decision (2026-06-06)

Approved. Add consumer-tunable strictness via real processor options (read from processingEnv.options, declared in @SupportedOptions — its correct use; see #14). Default stays strict; allow downgrading the missing-provider / non-contract-target diagnostics to warnings. Wire the option through KSP options / annotationProcessorArgs and document it.

[LMLiam]

Triage — confirm scope. This is opt-in configurability, not a defect: do you want consumer-tunable strictness (downgrade missing-provider / non-contract-target errors to warnings via a processor option)? If yes, it also gives a legitimate use for @SupportedOptions (currently misused — see #14). Ties into #15. Left status:needs-triage pending a yes/no.

[LMLiam]

Triage — confirm scope. This is opt-in configurability, not a defect: do you want consumer-tunable strictness (downgrade missing-provider / non-contract-target errors to warnings via a processor option)? If yes, it also gives a legitimate use for @SupportedOptions (currently misused — see #14). Ties into #15. Left status:needs-triage pending a yes/no.

Yes sure, this is a good idea.