Derive junit-platform-launcher and junit5Version from sbt-jupiter-interface plugin

[pjfanning]

Summary

Removes the hardcoded version numbers for junit-platform-launcher and junit5Version from project/Dependencies.scala. Instead, both are now derived at build time via the SettingKeys that the sbt-jupiter-interface plugin already exposes — ensuring they always stay in sync with the plugin.

Deprecates Junit 4 supporting classes.

Changes

project/Dependencies.scala

• Import JupiterKeys from com.github.sbt.junit.jupiter.sbt.Import (available on the meta-build classpath via addSbtPlugin)
• Add lazy val junit5TestDeps: Def.Initialize[Seq[ModuleID]] = Def.setting { ... } that reads versions from the plugin's own SettingKeys: JupiterKeys.jupiterVersion, JupiterKeys.junitJupiterVersion, and JupiterKeys.junitPlatformVersion
• Replace old net.aichler:jupiter-interface:0.11.1 with com.github.sbt.junit:jupiter-interface (current artifact coordinates), version also derived from the plugin
• Update all subproject dependency settings (httpCore, http2Tests, httpTestkit, httpTests, httpJackson, httpJackson3, docs) to use libraryDependencies ++= junit5TestDeps.value

How it works

JupiterPlugin exposes the JUnit versions it was built against as SBT SettingKeys (see JupiterPlugin.scala line 37):

junitPlatformVersion := readResourceProperty("jupiter-interface.properties", "junit.platform.version"),
junitJupiterVersion  := readResourceProperty("jupiter-interface.properties", "junit.jupiter.version"),
jupiterVersion       := readResourceProperty("jupiter-interface.properties", "version"),

Since the plugin is on the meta-build classpath, project/Dependencies.scala can import JupiterKeys and use those settings directly inside a Def.setting { } block — the same way SBT's own setting graph works — rather than duplicating the resource-reading logic.