Moved the files over from the experimental branch of WavefrontScheduling.
Removed the code for basic block scheduling as part of wavefront scheduling

During my post masters work I realized that the majority of the issues with my
wavefront scheduling implementation came from the basic block scheduler. Thus
it has been removed from this implementation as well.
Added a readme file to somewhat discuss the layout of this pass
Added construction/WavefrontInitialization.clp

This file contains the rules originally found in the WavefrontInit stage.

This code has been rewritten so that the wavefront objects are created first.
This has the side effect of being able to figure out which regions are capable
of being wavefront scheduled because there is a wavefront object associated
with it.
Added the wavefront-scheduling-pre-init module to Init.clp
Modified the PassHeader of wavefront-scheduling to load the rest of pass code

This includes the construction folder and the scheduler folder
Renamed StageGroupLoader.clp to Loader.clp
Updated WavefrontInitialization.clp to use modules

The code has been rewritten to also use messages as well.
Modified Loader.clp to do more than just load other files

Now it also contains the defmodules for the code in this folder as well as the
rule that performs the macro expansion in the pass-description object.
Updated the readme in scheduler to reflect the module name is -code not -proper
Rewrote ValidBlockIdentification to be simpler and use modules

I found several areas where I was taking a fact with a multifield and
converting each element into it's own fact through the use of individual rule
fires. I believe at the time I was trying to be more "expert system" like but I
realized that it would be faster to use a progn$ in a single rule to do the
same thing. This increases the amount of work the rule does but reduces the
overall number of rules that need to be fired.
Added two new modules to Loader.clp

The two modules are wavefront-scheduling-identify and
wavefront-scheduling-pathing.

The first module (wavefront-scheduling-identify) is responsible for identifying
which blocks on the wavefront can be scheduled into. A block is considered a
valid target for scheduling into if it only has one successor. Blocks that have
more than one successor or no successors are not allowed.

The second module (wavefront-scheduling-pathing) is responsible for figuring
out the "range" of blocks that follow the target block which can be scheduled
out of and into the target block. The code used to identify this was rewritten
to not use the (return) command because that command removes an element from
the focus stack if modules are used. While the pipeline manager is robust, it
will be be able to continue execution if the focus stack has the pipeline
module removed from being executed next.

I also modified some of the internal facts generated by the modules to use
messages instead to allow me to use the modify command instead of retract and
assert. This reduces the amount of typing I have to do and, according to the
documentation, the memory that represents the original template is reused and
modified which saves space.
Defined the rest of the modules for wavefront-scheduling in Loader.clp
Started porting the rules in WavefrontScheduling.clp

I finished the wavefront-schedule-inject and wavefront-scheduling-strip
modules. I rewrote some of the more complex rules to copy block sets over if it
turns out that the multifield being stored into is empty. This makes some of
the rules constant in the best case and linear in the worst case now (this does
not include CLIPS' internal overhead though)
Finished porting the wavefront-scheduling-acquire module

I rewrote the CPV rules to do one massive update to the corresponding object to
reduce the number of entrances into the object itself.
Finished porting the wavefront-scheduling-slice module
Fixed a naming issue with one of the modules in the macro-expand rule
Added the post-ponder module

This module executes marks blocks as closed on the wavefront. This divergence
from the original code was necessary because the modification of next pass set
requires that we get back to the pipeline first. In the original code, the
changing of the substage fact would preclude execution of
FinishedSchedulingIntoBlock. However, in the module version it is necessary to
push FinishedSchedulingIntoBlock into its own module instead.
Finished porting WavefrontScheduling.clp
Reformatted WavefrontScheduling.clp