Asynchronous for-loops not yet implemented

[arizvisa]

(This is just a placeholder for tracking, as I'll probably add this at some point unless someone else is interested)

Support for asynchronous for loops (PEP-530) is currently not implemented. This will require an implementation of the END_ASYNC_FOR opcode, as well as convincing the compiler at Python/compile.c to parse and emit it.

I'm assuming this wasn't implemented because its opcode (54) clashes with the STORE_MAP(54) opcode. A new constant will need to be decided upon for the opcode because changing it will have the side-effect of requiring all existing bytecode to be re-compiled which not only kills backwards-compatibility, but may be impossible in situations such as when only the .pyc bytecode is available.

[arizvisa]

Actually, if we could somehow expose the PyImport_GetMagicNumber value from the .pyc to the opcode decoder, we might be able to support these types of Python3 opcode collisions, or rather we'd be able to map opcodes from different versions of the bytecode to their correct implementation.

I'd consider this type of solution to be pretty crazy though, heh.