Make adapt-migrations honour logLevels via an injected logger

[taylortom]

Problem

adapt-migrations uses its own Logger singleton (Logger.getInstance()) which writes info/debug/warn directly to console. The AT's logLevels config has no effect on it.

In a typical run there are hundreds of lines per migrated combo:

(date) -- info --  Describe -- ... -- Registered
(date) -- info --  whereFromPlugin -- ... -- (stopped/success)
(date) -- info --  whereContent -- ... -- (success)
(date) -- info --  mutateContent -- ... -- (success)
(date) -- info --  checkContent -- ... -- (success)
(date) -- info --  updatePlugin -- ... -- (success)

This makes the AT's own logs (and any console.log debugging) practically unreadable during imports/updates. The migration trace is rarely useful unless something goes wrong.

Preferred fix: injected logger honouring logLevels (upstream)

The clean fix is upstream: have adapt-migrations accept an injected logger (or expose Logger.setLevel() / Logger.setOutput()) instead of writing through a hardcoded console singleton. AT then hands it a logger bound to the app's existing logLevels config, so migration info/debug is suppressed by the same mechanism as everything else — no second log destination to remember, no rotation to build.

This is the same root cause as:

• migrate() swallows failed migration steps instead of propagating the error adaptlearning/adapt-migrations#65 — migrate() swallows failed steps instead of propagating the error
• Revert content-migration error-capturing workaround once adapt-migrations propagates errors #217 — the createErrorCapturingLogger workaround that wraps the same singleton to detect errors

A proper injected-logger seam solves the noise (this issue), the error propagation (#65), and lets us drop the monkey-patch (#217) in one move, rather than stacking independent patches on one third-party singleton.

Why not "route to a file" (previous proposal)

The earlier proposal here — a migrationLogFile config that monkey-patches Logger.getInstance().info/.debug/.warn to append to a file — was rejected:

• The real want is to suppress the noise, not to relocate it to a file you have to know to go read.
• A separate file splits logs across two places and needs rotation/cleanup nobody will build.
• Monkey-patching a third-party singleton is fragile and would be the second independent patch on the same object (alongside Revert content-migration error-capturing workaround once adapt-migrations propagates errors #217).

Cheap interim option

If relief is needed before the upstream seam lands, gate migration info/debug behind the existing logLevels config on the AT side (still a patch, but no new file/config surface and no divergence from how the rest of the app logs).