Add support for "overflow" to POCOs

[ewoutkramer]

At this moment, POCOs only have properties for the elements defined in the FHIR specification. In many POCO serialization/deserialization frameworks, there is support for overflow, where "unknown" data can still be retained while parsing, and thus be processed and serialized later on. Also, metadata can be modified to supply type information for such unknown properties. Implemented at its fullest we could:

• Deserialize unknown properties to a kind of Dictionary that all resources support (part of Base?). If we don't have type information for that property, we would represent the contents of the json as a Dictionary.
• If we would have type information, we could parse such unknown elements into the proper FHIR datatypes. This could be done by providing type information as described in Change ClassMappings so it can support custom resources  #2850.

Going even further we could try to support not only unknown, but incorrect data too:

• repeating data if the property does not repeat (put those extra repeats in the overflow dictionary?)
• mistyped data, especially when dealing with choices
• unknown resources, by introducing a fully dynamic (e.g. overflow-only) base resource (which we've dubbed "DynamicResource" for now).

This would greatly enhance our capabilities to deal with newer data by older clients, or start working with newer (unpublished) versions of FHIR, without having to work with prereleases or multiple versions of the SDK. Or even fully custom resources.

There are numerous ways to achieve this, and also a number of issues that may arise, and I will just start off a list below:

• This will require changing the parsers and serializers to know about overflow.
• Unless we make them work against IDictionary (with setters), so that the implementation of this interface will either store it as a real property, or store it in an overflow dictionary.
• It would change our current error categories and parser family definitions. E.g. "Ostrich" will become even more flexible and the whole notion of whether parsing would discard information will shift too.
• When dealing with unknown properties (so, also no metadata as per Change ClassMappings so it can support custom resources  #2850 available), we could store the unknown data as dictionaries, but there will always be differences whether the source is json or xml which cannot be reconciled. The developer would have to deal with this.
• We have found that implementing IReadOnlyDictionary directly by POCO's confuses libraries and tools and we would like to undo that design. This means that, if we chose to implement IDictionary, we should also not directly do this on the public interface of a resource. The projected C# 13 extension interfaces and adapters would have been a great help here, if they'd ever see the light.
• We could tune the current PocoBuilder to exploit Overflow/dynamicresource so we can fully support bridging ITypedElement with POCOs.