change processing model for bugfixing loop

[atsushieno]

There are couple of source conditions defined as UNHACK_LOOP. Right now the compiler treats the loop controllers ('[', ']', ':' and '/') as predefined operators. They are wrong. They must be defined as a mere macro for each.

Currently UNHACK_LOOP cannot be enabled because of the current processing model of MmlOperationUses.
When resolving macros into flatten stream of MIDI events, they are converted from within the list of MmlOperationUse which are either from the track MML or macro definitions.
When those loop controllers are being expanded as macro, the content is nothing and no content of the loop will be iterated.

To fix this issue, the MmlOperationUses must be stored first, and then they have to be expanded.

There is another source condition labeled as LOOP_BY_RESULT, which actually does somewhat similar to the desired model explained above. But it expands the loop contents as the result of first iteration of MML processing. It will break operators that depend on loop, e.g. spectra. So it is actually no-go.

There is another difficulty in the processing model switch.
A simple desired processing model would be that Loop class structure stores a list of source MmlOperationUses while processing them, and at the end of the loop it expands the stored ones just like the compiler does right now (but remember that current list does not work across macros i.e. macro ']' will break that).
It seems simple but doesn't work... When expanding macros we need to resolve variables and macro arguments (call it "context" here), but this context information is lost after "flattening" macros and those operators cannot be re-processed afterwards. To make it doable, we need to preserve the context changes (which I'm afraid that it's going to be too much to process).

Or somehow change the way how context list of MmlOperationUses are resolved. That might be easier.

[atsushieno]

Also, we cannot simply "#define" those operators, especially ':', because ':' is also used to define the type of a variable (e.g. "gate : length").

[atsushieno]

After a couple of attempts to fix this, I'm going to mark this as by design. There is almost no practical benefit to fix this, while the impact of the changes are big and they tend to be inefficient solution.