[sv-ec] proposal for section 15 - scheduling semantics

Based on the discussions we've had towards resolving the scheduling semantics problems raised by issue 549 (and others), I've created a concrete scheduling semantics proposal. I hope that by having this document, we may converge quickly and vote on it. To avoid the confusion that ensued from the verbal discussions, and to show the extent of the changes to the LRM, I decided to include the entire section 15 and highlight the actual changes.

This is what I did in the attached proposal for section 15.  First, I incorporated all the change items for this section according to Mantis issues: 372, 707, 708, 709, 711, and 712. These have all been discussed and have either been approved or an agreement was reached as to what the proposal should be --- these changes are not highlighted.
Next, I applied the changes that correspond to what I believe is the proposal with the most consensus and the smallest set of changes to the existing LRM. All changes are shown in red (and an important deletion from Figure 15-1 is shown with a dashed gray arrow). Here is the summary of what those changes represent:

- Addition of one additional region: Re-inactive
    This region is used to schedule the process resumption due to #0 delay controls in program block code.

- Modified the reference algorithm and region diagram to create a Reactive sub-loop
    This corresponds to "approach II" in Gord's write-up, but with the following simplifications:
    a) NBA's are always scheduled in the NBA region
    b) Program-to-program NBAs are not supported - This is the same as the current limitation.
            In the future, this could easily be added via an additional Reactive-NBA region.

- The implications of this proposal are the same as in Gord's write-up
    a) #0 has a direct correlation to "normal" module delay controls
    b) Program processes can trigger each other with no interactions with the design
    c) More predictable behavior between "design" and "program" code.
    d) Atomic drive-back of values from program to the design (via the normal NBA mechanism).

If we accept this proposal then all other issues fall into place and can be quickly addressed by minor editorial changes.

    Arturo