... which makes Project.cpp a bit less dependent on some details of other
classes
This puts Tags.cpp back into the big strongly connected component of the
dependency graph. That will be remedied later when Project.cpp becomes a
low-level file
... To append files during recording or import, it doesn't depend on the
subclasses of BlockFile, instead taking a factory function to which it gives
the filename; and the choice of factory function is also lifted up through the
level of class Sequence which is just above DirManager.
This frees four files from dependency cycles, including DirManager.cpp but not
yet Sequence.cpp
... To do that, hoist the call to GetActiveProject() into the factory that
makes BatchEvalCommand
Also remove unnecessary inclusion of CommandBuilder.h.
This frees Command.cpp from dependency cycles; CommandBuilder and
ScriptCommandRelay are now in a small cycle of only two.
... This involved populating it with a new registration system.
BatchEvalCommand, HelpCommand, MessageCommand escape from cycles and move
higher in the dependency graph, and CommandDirectory moves lower.
... which by default used GetActiveProject(); do that call instead at a
higher level; so that AudacityCommand.cpp does not depend on Project.cpp.
We lose the override of that for CompareAudioCommand which just did nothing.
But in fact this overload of the base class method could only be used
by EffectUIHost constructed from a command, which never happened: it was only
ever constructed from effects.
This frees two files from dependency cycles
... which called ::GetActiveProject(), but one purpose of the CommandContext
class was to eliminate many uses of that global function, because a
CommandContext must always be constructed from a reference to a project
(which was always in fact the active one), then passed around to where it is
needed!
Also, just use the project member directly -- because CommandContext was
intended as just a P.O.D (plain-old-data) structure.
This also eliminates a dependency of CommandContext.cpp on Project.cpp.
This is not enough by itself to break any dependency cycles.
... freeing three files from dependency cycles.
The class is only constructed by ODManager so move its definition there.
Meanwhile, the (now misnamed) ODTaskThread.cpp implements some thread
synchronization utilities used in several other places, not dependent now on
ODManager.cpp, and also not on ODTask.cpp.
These utilities should be eliminated in favor of standard library alternatives,
but that is a task for later.
