`odoo.tools.sql.SQL` was added in Odoo 17, and for the most part it's worked quite well.

This PR aims to start the process of making it required for SQL queries, alongside simpler CI (the removal of the existing complicated pylint checker and the requirement of a semgrep that's both stricter and dumber).

Most of the changes are straightforward if wide ranging, however a few core changes stand out:

- support for strings in `Query.order` and `Query.add_where` has been removed, as they're essentially the same as concatenating unchecked strings into SQL queries (completely unnecessarily)
- because semgrep has limited support for interprocedural analysis and none for typechecking, it gets confused by things like
     ```python
     def foo(self):
         return SQL("SELECT 1")
     def bar(self):
          self.env.cr.execute(self.foo())
     ```
    Because extracting bits and pieces into their own functions is both reasonable and a commmon pattern when building up queries, a fastpath was added for the case of `SQL("%s", var)`[^1], this essentially passes `var` through unchanged *if it's already an `SQL`*, which means it can be used as a safe *and* cheap way to whitelist the value for semgrep that something is fine.
- `cursor.execute_values(str)` is deprecated, it should receive a `Composable`
- `cursor.execute(str)` is not deprecated yet
  -  there are >150 extant literal-string queries (which have no safety issues but would likely still need to be migrated)
  - `SQL` is not currently available in server actions, and the risk of exposing it has not been studied (though at first glance I don't really see more risks with it than with string queries)

## t-strings

Python 3.14 introduces t-strings, which would make *some* migrations simpler. However a lot of the migration work is from sub-queries needing to be migrated, which t-strings would not affect that materially. Debian Forky won't release until 2027 (if not delayed) and it's currently still on Python 3.13 (so is sid). Likewise Ubuntu 26.04 (the next LTS) although it does have 3.14 available as an optional additional (https://packages.ubuntu.com/search?keywords=python3.14).

While I do believe t-strings will make queries more convenient without loss of safety I don't think they make the migration so much easier that there is a good reason to wait *years* before committing.

## Static analysis

The more local behaviour allows for simpler static analysis (especially backed by dynamic checks): use semgrep to check that `SQL` calls only receive a literal first argument, and that `execute` only receives `SQL` objects[^2][^3]. This is slightly hampered by some limitations of semgrep e.g. semgrep sees

    foo = "bar"
    thing(foo)

as equivalent to

    thing("bar")

but such is not the case for bespoke types / expressions. In theory [symbolic propagation](https://semgrep.dev/docs/writing-rules/experiments/symbolic-propagation) does that but it doesn't seem to always work, and furthermore as noted does not work in all cases (e.g. symbols don't currently propagate past branches).

This PR recommends resolving those issues via `SQL("%s", previously_generated_sql)` which it special cases (via an optimisation).

This PR has little to no effect on pylint: while the SQL linter is complex and brittle, experimentally removing it has limited impact on the pylint run time. However it's a big piece of the *motivation* for using pylint,  removing it makes for a strong argument to eventually remove the pylint test entirely, replacing its various bits with other linters (ruff or semgrep rules, bespoke handrolled `ast`-based checkers).

odools might eventually handle this even better through models-aware typechecking, but it's currently far from being there.

## Possible Concerns

- how to make server actions work with this system (just expose `SQL`?)
  - how to *transition* server actions (catch the warning and notify the admin?)
- `sql.Identifier(sqlype)` sort-of works but becomes case-sensitive (as with other identifiers), and the quoting of attributed types can be temperamental e.g. `CAST(1 as "numeric"(5, 3))` works but `CAST(1 as "char"(3))` fails with "type modifier is not allowed". After more experimentation, `char` seems to be a specifically non-working type, varchar, bit, time do work although the date/time fields in their standard (expanded) form seem extremely temperamental.

[^1]: well it also allows setting `to_flush` as that seems harmless and there's one case which was [committing a mess](https://github.com/odoo/odoo/blob/26440c28f8a242484959afc3d7993b40e4237e04/odoo/orm/models.py#L3245-L3247) for the sole purpose of updating the flushing
[^2]: the second part is not in this PR, but would be a good idea (if requiring a lot more migration time due to needing to take a decision wrt server actions)
[^3]: and eventually t-strings maybe