Compile patterns for creating model abstraction layer [DBZ-973]

Migrated from [DBZ-973](https://issues.redhat.com/browse/DBZ-973)

Depending on the use cases of CDC, it might be useful to establish an abstraction layer (or "anti-corruption layer") to reduce coupling of event consumers from structural changes in the captured model. E.g. they should be free to react at their own pace if a column in a captured table gets added or renamed.

On the website, we should compile a list of typical structural changes and how loose coupling of clients can be achieved in an abstraction layer.

||Change||Abstraction Layer Pattern||
|Column in captured table gets added|If optional, no action needed. If non-optional and required by Avro compatibility rules, make the field schema optional via an SMT (single message transform)|
|Column gets renamed|Use SMT to re-add field with old name|
|Column type gets changed|Use SMT to change field name, then re-add field using old type, if convertable from the new one. Whether it's feasible depends on the exact type of change, e.g. if the type got widened (INT -> BIGINT), the wider type should be used for some time while still sticking to the original value range; that way customers can adjust there schemas to be prepared for receiving larger values)
|Column gets dropped|Use SMT to re-add field with old name and default value|
|Table is spit up into two (e.g. Customer and CustomerExtendedInfo)|...|
|Association changes cardinality (e.g. Customer goes from single address to n ones|...|