fix: validate Spark NLP by classpath probe, not spark.jars.packages string

[d0choa]

What

Replace OnToma's spark.jars.packages string check with a JVM capability probe
that validates Spark NLP is actually on the classpath.

Why

OnToma.__post_init__ guarded on spark.jars.packages containing "spark-nlp":

if not self._check_spark_config(spark, "spark.jars.packages", "spark-nlp"):
    raise ValueError("Spark session is missing configuration required for Spark NLP.")

That inspects how the jars were declared, not whether they are available.
Spark NLP can be loaded in ways that never populate spark.jars.packages:

• spark.jars — a pre-resolved fat/assembly jar (localized from GCS, no Ivy);
• a custom Spark image that bundles com.johnsnowlabs.nlp:spark-nlp.

In both cases the classes are on the classpath but the guard raises a false
negative. This is exactly the situation in the Open Targets PTS pipeline, where
we are moving the Dataproc clusters off spark.jars.packages (per-spark-submit
Ivy resolution against Maven Central) onto a pre-staged fat jar via spark.jars
(see opentargets/issues#4453).

How

py4j resolves a class that is on the classpath to a JavaClass and an absent
one to a JavaPackage. The new _spark_nlp_available() looks up the Spark NLP
entrypoint (com.johnsnowlabs.nlp.DocumentAssembler) on the JVM and checks the
resolved type — validating the capability directly, agnostic to how the jars
were loaded. The raised error now names all three valid load mechanisms.

Tests

tests/test_spark_nlp_check.py (TDD — written before the implementation):

• probe returns True when the entrypoint resolves to a JavaClass (even with
  spark.jars.packages unset);
• returns False when it resolves to a JavaPackage (class absent);
• returns False when the JVM lookup raises;
• integration: against a real Spark session with Spark NLP loaded, the probe
  resolves the class on the live JVM and reports it available.

tests/test_spark_nlp_check.py ....                                       [100%]
4 passed

Also adds setuptools to the dev group: pyspark==3.5.7 imports distutils,
which is absent on the Python >=3.12 this project supports (requires-python),
so the suite could not otherwise be collected there.

Version

Patch bump 2.5.1 → 2.5.2 (backward-compatible: strictly widens what passes
the guard).