Add support to two input process method.

[miroslavpojer]

Summary

v2.4.0 of the sbt plugin uses the 3-arg Command.process(String, State, onParseError) overload,
which was added in sbt 1.10.0. On sbt 1.9.x, running jacocoCleanAll / jacocoReportAll fails
with:

java.lang.NoSuchMethodError: sbt.Command$.process(...)

The plugin's README advertises "sbt 1.x", so this is a regression against the documented contract
and blocks adoption in projects that deliberately pin an older-but-supported sbt (which, via sbt
1.10's SIP-51 enforcement, would otherwise cascade into forced scalaVersion / semanticdb bumps).

Fixes #76.

Root cause

sbt-plugin/src/main/scala/morana/coverage/JacocoFilterPlugin.scala calls the 3-arg overload in
both aggregate commands:

Command.process(s"${ref.project}/jacocoClean",  st, msg => sys.error(msg)) // ~L56
Command.process(s"${ref.project}/jacocoReport", st, msg => sys.error(msg)) // ~L74

Verified against sbt sources: main-command/src/main/scala/sbt/Command.scala at v1.9.9 exposes
only process(String, State); v1.10.0 adds the 3-arg overload and @deprecateds the 2-arg one.

Changes

• JacocoFilterPlugin.scala — both calls switched to the 2-arg
  Command.process(String, State) overload, which exists across all sbt 1.x. The onParseError
  callback only fires on a malformed command string (not on command-execution failure), and the
  2-arg overload still returns a failed state on parse error, so the build still fails as before.
• build.sbt — pinned pluginCrossBuild / sbtVersion := "1.9.0" for the sbtPlugin module so
  it compiles against the oldest supported sbt API and cannot silently pick up 1.10+ methods again.
  The dev build still runs on the sbt.version in project/build.properties.
• integration-tests/fixtures/sbt-19x/ + integration-tests/test-sbt-19x.sh — new self-contained
  fixture pinned to sbt.version=1.9.9. The test asserts the launcher is on sbt 1.9.x, then runs
  sbt clean test and the full jacoco flow; jacocoReportAll invokes Command.process, so a
  regression to a newer-than-1.9 sbt API fails the test. Picked up automatically by run-all.sh
  (the test-*.sh glob), so the existing integration CI job runs it with no workflow change.
• integration-tests/README.md — documented the new fixture and test row.
• CHANGELOG.md — new Unreleased -> Fixed entry.

Compatibility

• One published artifact (jacoco-method-filter-sbt_2.12_1.0) continues to serve all sbt 1.x
  consumers; plugins resolve under the shared 1.0 binary bucket.
• sbt 1.9.x: NoSuchMethodError is gone.
• sbt 1.10.x / 1.11.x: unchanged behavior. The 2-arg overload is @deprecated there but still
  present and binary-compatible; the build has no fatal-warnings, so it is a non-issue.
• No changes to rule syntax, task names, settings, or artifact coordinates.

Testing

• Compile-time guard: the ci job's sbt test compiles the sbtPlugin module against the
  sbt 1.9.0 jars (via pluginCrossBuild / sbtVersion), so any accidental use of a newer-than-1.9
  sbt API now fails CI.
• Runtime guard: test-sbt-19x.sh (this PR) runs the plugin on an actual sbt 1.9.9 launcher and
  exercises jacocoReportAll → Command.process end-to-end — the exact NoSuchMethodError path
  from Lower minimum sbt version below 1.10 (avoid 3-arg Command.process) #76. Runs in the existing integration CI job via run-all.sh.
• Not verified locally (no sbt on the authoring machine); relies on CI.

Release notes:

• Fixed the sbt plugin failing on sbt 1.9.x with
  java.lang.NoSuchMethodError: sbt.Command$.process(...) when running jacocoCleanAll /
  jacocoReportAll — v2.4.0 had started using the 3-arg Command.process overload that only
  exists in sbt 1.10.0+.
• The plugin now compiles against the sbt 1.9.0 API (pluginCrossBuild / sbtVersion), so it can no
  longer regress onto newer-than-1.9 sbt APIs. sbt 1.x compatibility is restored; one published
  artifact still serves every sbt 1.x version.

Closes #76