MSH.9.2 returns MSH.9.1 value

[Brian Cragun]

Describe the bug
If referencing MSH.9.2 or MSH.9.3, the value for MSH.9.1 is returned. This happens in many cases but we have found one case where it works.

To Reproduce
In Address.yml, change addressee var to MSH.9.2:

line:
     type: STRING
     valueOf: 'GeneralUtils.makeStringArray( street, suiteApt, addressee)'
     generateList: true
     expressionType: JEXL
     vars:
          street: String, XAD.1
          suiteApt: String, XAD.2
          addressee: String, MSH.9.2

Run a test patient, such as Hl7AddressFHIRConversionTest.java, which has an MSH.9 with multiple values. Example: |VXU^V04^VXU_V04|

The output in the address is:

 "address": [ {
        "type": "postal",
        "line": [ "123 Any St", "VXU" ],
        "city": "Somewhere",
        "state": "WI",
        "postalCode": "54000"
      } ]

Expected behavior
MSH.9.2 should return the second value in MSH.9

Additional context
The value returns correctly in this case:

In MessageHeader.yml, change id as follows:

id:
  type: STRING
  valueOf: MSH.9.2
  expressionType: HL7Spec

[Joel Maner]

Once this bug is complete we should be able to remove MSH from the additional segments of all the message resources. They were added for story 139 because MSH 9.2 and MSH 9.3 were resolving to MSH 9.1. Adding MSH to all the additional segments fixed it but that is essentially just a workaround.
See #160 for files changed

[Lisa Wellman]

HL7DataExtractor is the suspected location of this bug