Generalize handling of Base/Conformance properties that changed type

[ewoutkramer]

This change makes sure that, in base/conformance, if we have a (primitive) property that changed type from version to version (like Attachment.size), the property is now of the abstract subclass PrimitiveType. (this PR actually would handle non-primitives too, but there isn't yet anything to test that with).

For such elements:

• The element changed type from whatever we picked (e.g. Integer64 for Attachtment.size) to a base class (in the case of primitive properties, to PrimitiveType)
• There will be helper properties with the correct type for each version. The most current will have the normal element name (Size in this case), while the older one(s) will have the FHIR type appended to them (SizeUnsignedInt).
• The documentation for the properties will make it clear when to use which property.

Note that the generated code is smart enough to know that, when generating helper getters, the actual type of the backing element does not matter, as long as they have the same .NET primitive constants. In all other cases, the helper getters will throw if the backing element has the wrong type.

The setters for the helper properties will always create the correct type in the backing element property.

E.g. if we're talking about Attachment.size, the accessor returning a long requires the SizeElement to be a FHIR Integer64. If it encounters an UnsignedInt there, the getter will throw. But for ElementDefinition.description, the getter of both versions (one for markdown one for FHIR string) will work, as both Markdown and FhirString have a string in their Value property.

I have also added [AllowedTypes] to such changed properties, as the abstract property type allows too many types. Obviously, the allowedtypes are exactly the sum of the types declared per version. We could make this validation more precise, if the validation attributes would be sensitive to FHIR version, which they are not yet. I have created an isse (FirelyTeam/firely-net-sdk#2982) to fix this in the future. For now, I generate these attributes with a "since" as comment lines.

To be able to generate these [AllowedTypes] attributes, I had to refactor the code a bit to avoid re-duplicating the existing code that generates this attribute for choicetypes.