Towards fewer script processing passes

Work after v0.4.2c is in progress to reduce the number of processing passes from the parsing end to the audio rendering end. It matters little for present features (actually it's been easier to make things work with more passes, requiring new insights to have fewer and make it still fully work). But a longer-term goal *could* be to adapt this system for live coding, and then multiple passes going through a script won't work as a design. Reducing passes to two also seems optimal for a design without live coding (given no compelling reason for more passes), and that seems good to do before adding more complexity. Some reductions in passes are smaller design adjustments that simply increase efficiency. A smaller change (in the stable branch) is that there's no longer any full postparse loop going through nodes in the parser, as all that is now done per durgroup rather than per script. Beyond that, it's now also in reach to remove a main layer between the parser and the generator/interpreter. Voice allocation doesn't need a separate pass (and is moved to parser per durgroup in the stable branch). This means the parseconv module can be done away with. But some questions remain as to where to place things, how exactly to divide things up between the two remaining ends, or main parts of the program. In the defunct experimental redesign branches that added features on top of something close to a 2011 "mgensys" version of the program, there were likewise only two layers (it was based on the program *before* the middle layer had came about). Some other "sgensys" and saugns features were missing making the task simpler, and I simply made a layer like parseconv + generator at the generator end. In a new, main, more incremental redesign to keep, it may be better to place more at the parser end -- meaning a leaner and meaner generator/interpreter end -- but how much? Remaining in the parseconv middle is: 1) Creating and assigning arrays of node IDs, used for traversal later. 2) "Voice traversal" code only needed for the `-p` printouts (audio rendering does it differently), which depends on the former. It's difficult to tell whether future features will require a different kind of node ID than presently used. The object IDs simply increase without ever being recycled. In the generator/interpreter, it may eventually be best to use a second kind of ID (separate op IDs), allocated to minimize how high they go. Such op IDs are more involved to allocate optimally than voice numbers, it's not yet been attempted in my program. It may become trickier with future features, too, which add more in the way of control flow. However, I think in theory it should always be possible to calculate ahead how a non-Turing complete interpreter will handle timing, etc., pre-running that part to the extent needed, if needed in the future -- though a restriction on number of script processing passes may limit features. So while a little more challenging, I lean towards doing as much as possible in the parsing end of the program; I think it'll be worth it in the end. (It will also mean a smaller design gap between such a design and some future one-pass design, should such become needed for an attempt at live coding.)