Command Groups - Update Composition Diagram to Clarify Behavior of "ParallelCommandGroup"

[PeterJohnson]

[Duplicated from artf5901 on the beta test site]

On the 2020 Online Documentation web page for Command Groups at https://frc-docs.readthedocs.io/en/latest/docs/software/commandbased/command-groups.html#recursive-composition-of-command-groups the diagram depicting the control flow of the "command group with concurrency" is a bit misleading. In the example, there is a SequentialCommandGroup of DriveToGoal(), ParallelCommandGroup(RaiseElevator(), SetWristPosition()), and ScoreTube(). The diagram (as of the time of this tracker item) implies that the ScoreTube() command commences after the RaiseElevator() command finishes, regardless of the status of the SetWristPosition() command. The diagram should be clarified to indicate that the ScoreTube() command does not commence until both the RaiseElevator() and SetWristPosition() commands have finished.

I have attached a couple images which depict (a) the referenced image at the time of this writing, and (b) an updated image showing what the diagram could be clarified to look like. (Both are attached.) Obviously, the updated image would look better than what I have provided if the original editing tool to generate the image could be used instead of my crude markup of the original image in MS Paint.

(Incidentally, the original image is a reasonable depiction of the control flow if the composition were ParallelDeadlineGroup(RaiseElevator(), SetWristPosition()), but I wouldn't recommend using the DeadlineGroup example as the basic example of parallel composition.)

[Daltz333]

@Oblarg

[Oblarg]

Yeah, this should be fixed. I'm terrible at making diagrams, though.

[modelmat]

The original block diagram has been recreated in GraphViz. If anyone wants to PR it to my branch to add the second text feel free.
If not I will (next month).