[python] expand comprehensions into for loops via for_in_clause

[alexpw]

This rewrites {set,list,dictionary}_ comprehensions into it's expanded for loop form. Unlike the if/else <-> ternary code, this can safely preserve all comments.

Notice: It does not support an action to toggle back to a comprehension as I haven't wrapped my head around how to approach that, except for in a very narrow case.

Warn: The most questionable thing is a decision made in order to support return statements, eg, return [x for x in range(10)]. The expanded form requires a variable to hold the list that is initialized, appended to, and returned, but there's no identifier name in this case. So, I either had to choose one, or prompt the user for one, ie with vim.fn.input(). I opted not to prompt and chose a generic/friendly name, result, instead of a generated collision-proof one like _list_accumulator_fda43. That means the comprehension's expanded form looks like:

result = []
for x in range(10):
    result.append(x)
return result

Tests include an "absurd" case to show that it supports many fors, ifs, comments, and multiline everything, everywhere, all at once.

[CKolkey]

Great stuff. The 'result' variable seems fine to me. Gotta put the data somewhere. I'm a little hesitant about this being a one-way transformation, but its not a dealbreaker. Whats the current issue you're facing when transforming them in the other direction?

[alexpw]

Hmm, two-way is possible, but at the time it felt overwhelming. 😅 It just requires a bit of strict analysis to know if it's safe to reverse it.

1. there must be an assignment, eg, list1 = [], defined immediately before the loop.
2. there can be only 1 (non-for/non-if) statement in the body, it must be the deepest child, and it needs to be an append(), add(), or key=value acting on the list1 identifier.
3. if the next sibling of the parent for loop is a simple return list1, then it will be return {comprehension} instead of an assignment.

That might actually be all of it. I'll go ahead and implement it.

[CKolkey]

Cool. No rush on it either - by all means, take your time to explore the solution. I'm not sure if it's of any help, but some of the modules in treesitter-refactor (https://github.com/nvim-treesitter/nvim-treesitter-refactor/blob/master/lua/nvim-treesitter-refactor/highlight_definitions.lua) might be useful to pull some semantic information out of the tree, like the variable name, or some such. Maybe, maybe not :P