v3.2: Add data vs serialized Example Object fields (Revised)

[handrews]

NOTE 1: Please review this for the functionality only, not the field names which are being tracked in release-blocker issue #4658.

NOTE 2: This PR is the main part of PR #4647, extracted and reworked to minimize the diff while addressing various points that have come up since I posted that PR, which will now be closed. The updated examples will be posted in different PRs (I tried to include the updated Example Object examples in this PR, but the diff gets really messy for reasons that are not clear to me- git can't figure out the "Example Object Examples" heading as a stable line for some reason).

This adds four fields to the Example Object.

dataValue and externalDataValue apply to the data that would be passed to schema validation.

serializedValue (which MUST be a string) and externalSerializedValue apply to the serialized form.

External values are used when the appropriate value cannot be included in JSON or YAML,

• [X] schema changes are included in this pull request
• [ ] schema changes are needed for this pull request but not done yet
• [ ] no schema changes are needed for this pull request

[handrews]

Force-pushed to fix check errors since no one had looked at this yet anyway.

[handrews]

I am not able to fix the schema test coverage issues due to issue #4693.

[handrews]

@hudlow @karenetheridge I have updated this and PR #4672 to not use the data fields for binary. @hudlow I dropped both your updated comment on unicode and binary and some of my remaining sentences as they seemed redundant. I think what remains covers what is needed.

[ralfhandl]

@handrews This PR extends schema.yaml and now also needs to add positive test cases for the new features. Please add.

[handrews]

@ralfhandl new commits added with tests. Otherwise the force-push is just a rebase with not conflicts (same commits).

[handrews]

Force-pushed a rebase to pick up the latest test runner changes. No conflicts or additions- these are literally the same commits as before.

[handrews]

@karenetheridge @hudlow @mikekistler in addition to the previously-mentioned use case for externalDataValue (which arose without me looking for such a thing), I also ended up using it in the XML example updates because again I needed to show the same input data serialized in two different ways in two different contexts. While this second use case is more contrived, it's not unrealistic, and that's two that have come up without me particularly trying to make it happen.

At this point, I am quite firm in thinking that we need both externalDataValue and externalSerializedValue (even if externalValue is well-defined as behaving like externalSerializedValue, the naming asymmetry is problematic).

[EDIT: PR #4648 shows even more potential use cases, where you are using the same dataValue at two different levels with different serializations]

[handrews]

I've marked this as draft as I am expecting to close it in favor of a new PR I've invited @hudlow to submit with his alternative proposal above.

[handrews]

Closing in favor of #4799.