Structured rich text element mapping

### Motivation

Allow Delivery SDK to work with [Structured rich text element](https://github.com/Kentico/kontent-generators-net#parameters).

### Proposed solution

* Allow model generators to generate rich text elements differently than just a string.
* Fill the structured rich text element model while mapping the data ([.NET implementation example](https://github.com/Kentico/kontent-delivery-sdk-net/wiki/Structured-Rich-text-rendering#structured-rich-text-data-model))

### Additional context

SDK has solid support for the Thymeleaf template engine - string-based rendering of the data.
Loading data for "API" endpoints currently require parsing the HTML and create a structure for rich text on the application site.

Sample item with multilevel nested components: https://deliver.kontent.ai/306d7f21-2609-01b0-6e1c-93cbc328a82d/items/rich_text_resolution

Simple pseudocode of the structure

```jsonc
{
elements: {
content: [ // rich text element
{
headline: { // component/content item
..
},
section: { // component/content item
content: [ // rich text element
{
headline: { // component/content item
text: [ // rich text element
{
text: "inner headline" // text element is an object too
}
]
}
}
]
}
}
]
}
}
```

Notes
* text is also the object for interoperability with components
* infinite loop - first version
* log a warning and does not resolve! WITH PROPER ITEM IDENTIFICATION ERROR MESSAGE

Start by tracing the model-generator and data-mapping entry points used for API responses, then compare the linked .NET structured rich text example and the nested sample item. Done means nested rich text and component/content items are represented as structured objects, including text objects, while recursive references produce a warning with a clear item identification error.

Written by the indexing model from the issue text.