The error messages in the parser module are referring to numeric IDs for the nodes. To improve readability, use the node names when reporting errors..
(cherry picked from commit cb0748d3939c31168ab5d3b80e3677494497d5e3)

Co-authored-by: tyomitch <tyomitch@gmail.com>

bpo-36256: Fix bug in parsermodule when parsing if statements

In the parser module, when validating nodes before starting the parsing with to create a ST in "parser_newstobject" there is a problem that appears when two arcs in the same DFA state has transitions with labels with the same type. For example, the DFA for if_stmt has a state with
two labels with the same type: "elif" and "else" (type NAME). The algorithm tries one by one the arcs until the label that starts the arc transition has a label with the same type of the current child label we are trying to accept. In this case, the arc for "elif" comes before the arc for "else"and passes this test (because the current child label is "else" and has the same type as "elif"). This lead to expecting a namedexpr_test (305) instead of a colon (11). The solution is to compare also the string representation (in case there is one) of the labels to see if the transition that we have is the correct one.
(cherry picked from commit 9a0000d15d27361eaa47b77600c7c00a9787a894)

Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>

Converting with line_info=False and col_info=True crashed before.
(cherry picked from commit e5362eaa75a154c6e91c5b1c47719d0a0f5ca48b)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

possible.  Patch is writen with Coccinelle.

with PyUnicode_AsUTF8 and PyUnicode_AsUTF8AndSize.

Patch from A. Skrobov.