Play Framework

refactor(deps): remove the orphaned play deps machinery from play.deps

The `play deps` command was removed in the 1.13.0 Gradle migration (PF-90),
but the Ivy-driving half of DependenciesManager went with it only in reach,
not in code: every one of those methods was left callable solely from a
main() nothing invokes.

Removed (reachable only from DependenciesManager.main):
  main, report, sync, canonicalOrSelf, problems, retrieve, install,
  moduleName, isFrameworkLocal, isPlayModule, resolve, configure
  — 428 of the class's 473 lines, plus all 67 lines of PlayConflictManager
  (constructed only by the dead configure()).

DependenciesManagerTest went too: its 3 tests exercised moduleName(), called
only from the dead install(). They were green while covering code that could
not execute, leaving the one live method — retrieveModules() — untested.

Kept: retrieveModules(), which Play.loadModules() uses to order modules from a
legacy app's conf/dependencies.yml. Retiring that path is a behavior change,
not a refactor, and is deliberately out of scope here (see PF-162).

The constructor's framework/userHome params were used only by the removed
methods, so it narrows to (application) and Play.loadModules drops the
now-unused userHome local. DependenciesManager is left with no Ivy imports at
all, which matches the traced reality: the runtime path reaches Ivy only
through YamlParser. Framework-level resolution (FrameworkResolve, PF-62) never
used this class and is untouched — its javadoc reference to the deleted
isFrameworkLocal is rewritten.

Verified: `ant test` green (unit + integration, the latter booting a real
Netty server through Play.loadModules); `ant resolve` still resolves 135
artifacts, 0 copied, 0 stray — confirming PlayConflictManager was never
wired into the live resolution path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>