Keep large dictionary displays inside comprehension elements

[EiNSTeiN-]

I am opening this PR to fix large dictionary displays used as comprehension elements. The code below currently confuses dictionary construction with the enclosing comprehension's own key/value operation and produces invalid source:

def select(rows):
    return [{
        "k0": row + 0, "k1": row + 1, "k2": row + 2, "k3": row + 3,
        "k4": row + 4, "k5": row + 5, "k6": row + 6, "k7": row + 7,
        "k8": row + 8, "k9": row + 9, "k10": row + 10, "k11": row + 11,
        "k12": row + 12, "k13": row + 13, "k14": row + 14, "k15": row + 15,
        "k16": row + 16, "k17": row + 17, "k18": row + 18, "k19": row + 19,
    } for row in rows]

A large dictionary literal uses MAP_ADD 1 while being built as a list-comprehension element. The parser currently interprets any active-comprehension MAP_ADD as the enclosing comprehension's own key/value operation, so dictionary fields can overwrite its element bookkeeping.

The fix makes the statement parser route argument-one collection operations to ordinary collection construction. The separate comprehension/generator walker also extends its current dictionary for MAP_ADD 1, rather than recording an enclosing key. The same display therefore remains a dictionary when used as a generator-expression element, ({...} for row in rows). Ordinary dictionary comprehensions, such as {row: row + 1 for row in rows}, keep their existing key/value handling.

CPython begins emitting this large-display layout in 3.10: compiler_subdict in 3.10 uses MAP_ADD 1 when the display exceeds its stack-use guideline; 3.9's compiler does not use that layout. Both guards therefore start at 3.10, including the separate-code-object comprehensions used before 3.12.