Move the change search from Velocity to Java

PR: #56

The search now lives in ChangeManager#search in the API module, and getChanges is a shim over $services.releasenotes.parseQuery plus search.

Verified as a pure refactor:

• GetChangesMacroPageTest keeps every one of its assertions on the generated statement and on the bound values; only its wiring changed, since the query is built through the QueryManager component now instead of $services.query. Same for ReleaseNotesChangesMacroPageTest and ReportPageTest.
• Rendered byte-for-byte identically on a real wiki with real data: the demo XAR was migrated to the 2.x format on the wiki a Docker IT run leaves behind, the rendered content of 8 pages was captured with the new macros, the two macro bodies were swapped back to their master versions over REST, and the same 8 pages were captured again. The 8.3, 8.3M1, 8.3M2 and 8.3RC1 release notes and 4 report variants (a >= version filter, a like filter, page 2 of a report, the grid displayer) are identical. The only difference in the whole set is a JIT frame inside a pre-existing "Failed to highlight content" stack trace that the minimal test wiki produces for a demo change's description.
• exclusions still work end to end: excluding one change from the 8.3M1 note removes that change and leaves the others, which is what the String contract of the context variable protects.
• ReleaseNotesIT: 10/10 green, so the new components register in a real wiki.

The one behaviour that changes is the one this issue asks for: the versions the wiki holds a release note for are selected in a single query, instead of loading every release note document to read one string.