Add Interchange Syntax Extension (ISX) from 2017 version 007040 forward to Sterling Envelope options

Walmart planned to do our first 008010 Purchase order will full UTF-8 encoding and defined release character support. We have an ITX map to support it but the Sterling Enveloping options are missing any 'include ISX' options.

Why is this needed? Walmart is implementing this map for both domestic and import orders and has a LOT of international customers. Imports specifically add a large amount of international text and by extention potential delimiter conflicts and X12 as a standard is way overdue for support these two items specifically that EDIFACT has supported for decades now. Hence why the ISX was added in 2017's 007040 and was implmented to be the first backward supportable segment all the way back to version 004010. (So even though we are doing this in version 008010 proper support per X12 should support this for any version 004010 or later (see 4.1 Restriction 1 - Applicable Versions.) Also, Walmart has long stuggles with conflicting delimiters especially with asterisk being our default element separator and our branding being WAL*MART for close to a decase, this pain has been real and we want to have options to get away from this.

How do we see this implemented?

For inbound: Honestly all this is already supported by Sterling already EDIFACT UNA0104 already lets data set a release character, EDIFACT UNB0101 already lets single character encoding be set on inbound transactions and if sent as UNOY then UNB0103 allows for multibyte encodings to be set. The first two elements are just copying things EDIFACT already supports.

The ISX03&04 simply duplicate, expand, and override the GS08 with respect to code list versioning.

For outbound: The ISA already prompts for and allows selection of release characters (for mutual agreement use cases) and Encoding so we already capture the first two elements of the ISX we only need a send ISX option and the ISX simply gets added after the ISA and before the GS. The ISX03 & ISX04 would then become additional options with a dependency that ISX04 requires the ISX03 but not the other way and these basically would function like the GS08 but with the first 6-characters being the ISX03 with the ability to go back to version 004010 and then the suffix portion VICS of X132 being the ISX04 which is likely a free-form text because we don't know what will be added.

What is the priority for this? Walmart has already completed a working 008010 UTF-8 map before we realized that the Sterling Envelope support of ISX was missing and we are already piloting with suppliers with a guide that we want to have version 008010 complete with ISX support to be published after the holidays. This is something added to X12 7-years ago now and it's going to be used as X12 continues into the modern era with greater diversity in internationalizated supply chains.