Fixed problem printing Penn Treebank parses for AGIGA-generated Communications

The previous version of the code made an assumption about how
Constituent Parses were stored that was true for Serif-generated
Communications but not for AGIGA-generated Communications.

Each Concrete constituent Parse object has a constituentList member
field.  With Serif, the first node in this list always has node ID 0,
the second node in the list always has ID 1, etc.  But with AGIGA, the
position of the node in the list is not always identical to the parse
node ID.