Support nested fstring

[Glyphack]

trafficstars

in both lexer and parser there is a nested fstring test case which is commented out because we don't support it.

This has to be implemented in the Lexer first and the parser don't need to change.

[Glyphack]

https://peps.python.org/pep-0701/

> Before the changes proposed in this document, there was no explicit limit in how f-strings can be nested, but the fact that string quotes cannot be reused inside the expression component of f-strings made it impossible to nest f-strings arbitrarily. In fact, this is the most nested-fstring that can be written:
>>> f"""{f'''{f'{f"{1+1}"}'}'''}"""
'2'
As this PEP allows placing any valid Python expression inside the expression component of the f-strings, it is now possible to reuse quotes and therefore is possible to nest f-strings arbitrarily:

>>> f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}"
'2'
Although this is just a consequence of allowing arbitrary expressions, the authors of this PEP do not believe that this is a fundamental benefit and we have decided that the language specification will not explicitly mandate that this nesting can be arbitrary. This is because allowing arbitrarily-deep nesting imposes a lot of extra complexity to the lexer implementation (particularly as lexer/parser pipelines need to allow “untokenizing” to support the ‘f-string debugging expressions’ and this is especially taxing when arbitrary nesting is allowed). Implementations are therefore free to impose a limit on the nesting depth if they need to. Note that this is not an uncommon situation, as the CPython implementation already imposes several limits all over the place, including a limit on the nesting depth of parentheses and brackets, a limit on the nesting of the blocks, a limit in the number of branches in if statements, a limit on the number of expressions in star-unpacking, etc.