Move solver to service package

[agusaldasoro]

Follow-up to #1696 (comment).

docs/for_developers.md asks that injectable services be singletons declared under a *.service package. SMTLibZ3DbConstraintSolver already met the first two conditions: BaseModule binds it with asEagerSingleton(), and ApiWsStructureMutator injects it. Only the package was wrong, so it moves to org.evomaster.core.database.sql.solver.service.

It is the only injectable in that package. SmtLibGenerator, SMTConditionVisitor, SmtTable and the DbConstraintSolver interface have no binding and nothing injects them, so they stay where they are. The moved file picks up two imports for the symbols it used to reach as package mates, and the rest of the production change is two import lines, in BaseModule and ApiWsStructureMutator. Nothing names the class as a string anywhere, so the Guice binding resolves exactly as before, and no behaviour changes.

Tests moved to match

The solver tests sat in org.evomaster.core.solver, a package matching nothing in production. Since a test suite is meant to live in the same package as its class under test, all ten move as well: SMTLibZ3DbConstraintSolverTest and UntranslatableQueryCacheTest into ...sql.solver.service, and the eight covering the generator, the visitor and the shared type vocabulary into ...sql.solver. Imports that became same-package are dropped. The corpus and scaling tests load their fixtures by absolute classpath path (/solver/sample-schema.json), so those are unaffected and the resources stay where they are.

[arcuri82]

@agusaldasoro hi. there are merge conflicts

[agusaldasoro]

@agusaldasoro hi. there are merge conflicts

Fixed!