Define schema generation strategy for schemaless datasources

[GregorioBlazquez]

After #176

Schema-based features (e.g. DA validation, schema exposure through the API, metadata persistence) require a well-defined FDA schema.

While this is straightforward for relational datasources, schemaless datasources such as MongoDB require additional design decisions.

This issue aims to define how the FDA schema should be generated and maintained for these datasources, including cases such as:

• Nested JSON documents.
• Arrays and complex objects.
• Fields with heterogeneous types across documents.
• Values that cannot be represented consistently in a tabular format.

The expected behaviour should be documented and covered by integration tests to ensure that every cached FDA can be materialized consistently as Parquet.

[fgalan]

To add more complexity to the problem ;), note that the structure of the data stored in MongoDB may change over time.

I mean, at a given moment t_0 (e.g. at FDA/DA creation time) we could have in MongoDB a query which results match perfectly in a given "schema" (i.e. all them have the same fields, etc.) but in another moment (e.g. a day after t_0) the results of the same query may have a different structure.