The search WSAPI accepts JSON conditions

[MikeTaylor]

This commit adds a jsonCond query parameter to GET /cyclops/sets/{setName} as a safe alternative to cond. The client sends the condition's structure as JSON rather than CCMS command language. mod-cyclops validates it and generates the condition itself, so a value can never be read as syntax. cond is unchanged and still works for now — the two are mutually exclusive, and supplying neither remains an unconditional retrieval. At some point, once ui-cyclops is updated to use jsonCond, the security-hole that is cond will go away.

The jsonCond parameter is simply URL-encoded JSON. The format is documented in ramls/cond-schema.json, with a motivating example in ramls/examples/cond.json. It represents a tree of clauses with an explicit type discriminator: and/or junctions, not, term (field + abstract relation + value), and filter references. Relations are abstract names (contains, ge, isNull), never CCMS operators, so the backend owns the whole mapping.

The JSON-condition decoder and CCMS-condition encoder live in cyclops/cond.go. DecodeCond builds the tree checking only shape; RenderCond checks it against an optional condition schema (currently vacuous) and emits a CCMS condition, quoting values using the existing sqlString/intval/ident helpers. Trees that are too deep, have too many nodes, or contain too-long list values are rejected.

The existing search handler handleRetrieve accepts either form of condition. requestCond resolves the two parameters and returns HTTP error 400 if both are supplied or a JSON condition is malformed.

Tests: there is a 37-file corpus of JSON conditions under ramls/condtest/ with its own Makefile, and it's wired into ramls/Makefile. There are also Go tests covering the corpus, the limits, operator injection, the permissive-schema behaviour, and the handler end to end.