Restore required elements and ordering on vastInLine_type and vastWrapper_type

[aleksUIX]

vastInLine_type and vastWrapper_type use <xs:choice minOccurs="0" maxOccurs="unbounded">. That compositor drops the cardinality of everything inside it: the children still declare minOccurs="1", but within a repeating optional choice that governs a single selection rather than the content model. Reported in #58.

Against the schema as it stands, all three of these validate:

<Ad id="a"><Wrapper/></Ad>                 <!-- no AdSystem, VASTAdTagURI or Impression -->
<Ad id="a"><InLine/></Ad>                  <!-- no AdSystem, AdTitle, Impression or Creatives -->
<InLine><AdSystem>A</AdSystem><AdSystem>B</AdSystem>...   <!-- AdSystem repeated -->

All three were rejected in 2.0 through 4.2. This changes both types to xs:sequence with the cardinality these elements have always had. No elements are added or removed.

On the ordering. I kept the 4.2 element order rather than the order the xs:choice happened to list them in, and that is not cosmetic. I tested the alternative: using 4.4's current listed order breaks all six VAST 4.1 and 4.2 files in VAST_Samples that validate against 4.4 today. The 4.2 order breaks none of them.

Regression testing. Ran the 33 4.1 and 4.2 samples with the version attribute rewritten to 4.4, so the fixed-value constraint does not mask the content model. Six pass before and after this change, zero newly broken. VAST 4.0 samples were excluded deliberately, since they predate AdServingId and would fail on a requirement that has held since 4.1 rather than on anything introduced here. Also confirmed the three cases above are now rejected and that ordinary inlines and wrappers still validate.

Separate, not addressed here. BlockedAdCategories on Wrapper and Expires on InLine exist in 4.2 but are not declared anywhere in vast_4.4.xsd, and neither is marked deprecated in the 4.3 text. A 4.4 wrapper carrying BlockedAdCategories is rejected today. Re-adding them needs type definitions, so I left them out of this change.

If the group would rather keep order independence than restore cardinality, I am happy to close this. As covered in #58, XSD 1.0 cannot give both: xs:all caps every particle at maxOccurs="1", and Impression has been 1..n since 2.0.