Add a `.code` alternative for all CSTNode subclasses about libcst

[DragonMinded]

There are some nodes (namely Annotation) that cannot be generated at all, unless they are being generated inside a parent. How do we want to handle those? Do we want to have a .code attribute only on nodes that are top-level (AKA where at least one of parse_statment(node.code), parse_expression(node.code) or parse_module(node.code) won't fail)?

[bgw]

@DragonMinded

I'd imagine that they'd either raise an exception (what Annotation does now), or just pick some default value for the missing information (e.g. an Arg with a sentinel comma just doesn't attach a comment). We should probably be consistent about how we handle it.

Either of these behaviors is no worse than how Module.code_for_node handles it.

Do we want to have a .code attribute only on nodes that are top-level

Annotation is the only node I know of that actually fails right now (instead of inserting a dummy value), so I think my preference would be to make it default to -> or : as the indicator, and implement the attribute/method on the CSTNode base class. That seems like the easiest way to implement this.

This kind of problem of nodes outputting different code depending on where they are in the tree isn't solvable. Even if you restrict what nodes support .code/.code_with_context, expressions or statements might still render differently because they don't know the current indentation level.

For that reason, I think we should just pick a name for our attribute or method that indicates that it's not going to be the same, or possibly that it's intended for debugging purposes.

[DragonMinded]

This isn't a priority, especially now that we have self.module.code_for_node helper attached to Codemods.