Provide public API for external polymorphic and/or sealed serializers

[qwwdfsad]

Currently, the general-purpose (i.e. not JSON-specific) polymorphism is supported only by subclassing AbstractPolymorphicSerializer with internal constructor.

The rationale is basically the same as in #2459: the library has to implement an external sealed class serializer (example: https://github.com/Kotlin/kotlinx-datetime/blob/master/core/common/src/serializers/DateTimeUnitSerializers.kt#L190) but in the manner that this is a public type that can be used as @Serializable(with = ExternalSerializer).

Implementing regular serializer via delegation does not do the trick because all the format mplementations check for is AbstractPolymorphicSerializer

[pdvrieze]

@qwwdfsad Not all formats, in XML I don't check for that type (try to rely on descriptors only). Its implementation handles
sealed and non-sealed separately, the default cases (no additional configuration) relying on the experimental SerializersModule.getPolymorphicDescriptors.

XML needs to do this as uses a two-phase approach where before serialization the system first builds up an extended type tree (without accessing serializer/serializer, only using the descriptors). This approach is there to have consistency between serialization and deserialization in a context where there is a policy that can influence how specific members are serialized.

The side-effect is that as long as the descriptor is "correct" (has a context) delegation of a polymorphic serializer is actually supported. It would be good if the SerialDescriptor wrapping function retained context though - that would allow renaming.

Looking at the problem, it should be perfectly possible to adjust the library so that the extension functions are no longer
AbstractPolymorphicSerializer<T>.findPolymorphicSerializer but instead Serializer<T>.findPolymorphicSerializer (or even just the descriptor).

Having said that, this is one of the two points in the API that are clumsy at best:

• Introspection of full types (with a given SerializersModule), including all possible polymorphic children - a workaround with a collector for the module is needed
• Handling lists in incremental mode (requires checking for CollectionSerializer), other forms of "updates" are not possible at all

[sandwwraith]

Related: #1715

[sandwwraith]

Related: #2721, #1865