Validator will not process root constraints for expanded datatypes

[ewoutkramer]

In issue #491, we discovered that when an element walks into a datatype, thus including its children in the snapshot, it does not include the invariants on the root of the included datatype. We discovered this specifically for Period, since that has invariants on its root

As a "quick fix", @andrzejskowronski created PR #521, which made sure that the validator is calling these root invariants anyway, but specifically fixed this for slices (value[x]. where x is Period). And decided we needed to fix this in the snapshot generator (FirelyTeam/firely-net-sdk#3156).

After discussions with Grahame on Zulip (https://chat.fhir.org/#narrow/channel/179177-conformance/topic/Where.20are.20the.20invariants.20on.20datatype.20roots.3F/with/529291761) we concluded adding these constraints to the snapshot is not appropriate (anymore). This means the validator has to account for this in its schema compilation, and make sure we're calling the root constraints.

This is, in effect, the work that @andrzejskowronski did on #521, but then for the more general case (521 works only on sliced elements, since we thought it only occurred there).

So, we need to:

• Expand the circumstances under which to run the extra constraints, from just choice elements to any element that has nested children (because we walked into the type).
• Reconsider whether we want to solves this by having this extra special validator (the BaseTypeInvariantsConstrainsValidator), or whether we want this as a special case of the SchemaReference validator (just running all the root invariants, not the children).