- Extends the scanner with a new token kind representing the start of atemplate string. This is used to distinguish template strings fromregular strings (because only a template string will start with a`_template_string_start` external token).- Cleans up the logic surrounding interpolations (and the method names)so that format strings and template strings behave the same in thiscase.Finally, we add two new node types in the tree-sitter grammar:- `template_string` behaves like format strings, but is a distinct type(mainly so that an implicit concatenation between template strings andregular strings becomes a syntax error).- `concatenated_template_string` is the counterpart of`concatenated_string`.However, internally, the string parts of a template strings are just thesame `string_content` nodes that are used in regular format strings. Wewill disambiguate these inside `tsg-python`.

Adds three new AST nodes to the mix:- `TemplateString` represents a t-string in Python 3.14- `TemplateStringPart` represents one of the string constituents of at-string. (The interpolated expressions are represented as `Expr` nodes,just like f-strings.)- `JoinedTemplateString` represents an implicit concatenation oftemplate strings.Importantly, we _completely avoid_ the complicated construction wecurrently do for format strings (as well as the confusing nomenclature).No extra injection of empty strings (so that a template string is astrict alternation of strings and expressions). A `JoinedTemplateString`simply has a list of template string children, and a `TemplateString`has a list of "values" which may be either `Expr` or`TemplateStringPart` nodes.If we ever find that we actually want the more complicated interface forthese strings, then I would much rather we reconstruct this inside of QLrather than in the parser.

We do the usual thing. Downgrade scripts remove the relevant relations;upgrade scripts do nothing.

Not actually based on any measurements, just the usual 100/1000 stuff.

Seehttps://peps.python.org/pep-0758/ for more details.We implement this by extending the syntax for exceptions and exceptiongroups so that the `type` field can now contain either an expression(which matches the old behaviour), or a comma-separated list of at leasttwo elements (representing the new behaviour).We model the latter case using a new node type `exception_list`, whichin `tsg-python` is simply mapped to a tuple. This means it matches theexisting behaviour (when the tuple is surrounded by parentheses)exactly, hence we don't need to change any other code.As a consequence of this, however, we cannot directly parse the Python2.7 syntax `except Foo, e: ...` as `except Foo as e: ...`, as this wouldintroduce an ambiguity in the grammar. Thus, we have removed support forthe (deprecated) 2.7-style syntax, and only allow `as` to indicatebinding of the exception. The syntax `except Foo, e: ...` continues tobe parsed (in particular, it's not suddenly a syntax error), but it willbe parsed as if it were `except (Foo, e): ...`, which may not give thecorrect results.In principle we could extend the QL libraries to account for this case(specifically when analysing Python 2 code). In practice, however, Iexpect this to have a minor impact on results, and not worth theadditional investment at this time.

Note in particular that the `exceptions.py` test is unaffected.