Add validation to flag exponential notation as incorrect in pre-R4 instances

[ewoutkramer]

Since the parser is in a shared codebase across the FHIR DSTUs, the addition of exponential notation for decimals in R4 has caused this notation to now be accepted for pre-R4 instances too. We should look at having a specific validation for DSTU2/STU3 to catch this and flag it as an error.

[brianpos]

Is the Serializer (output) doing the right thing?
If so then I'd live with this. As an implementer I'd be happy to accept these coming in on the old interface, as long as they didn't go out with it.

[ewoutkramer]

Yes, I am pretty sure it will never output exponentials - in fact our recent discussion with @kennethmyhra shows this indeed the case. Whether that's correct from the viewpoint of interop/roundtrippability is another issue...

[ewoutkramer]

When we have split up the validator into separately configurable validation blocks, we could add a block checking for this - and then decide on running it on a per DSTU basis.

[ewoutkramer]

We have now decided that, for the sake of sharing code, some newer features are allowed when parsing older data. Almost all of them are caught by profile validation (e.g. new enum values). This might not be, but I cannot be bothered.