[Feature request] Rework <teal_module>$server to get teal_data object

[gogonzo]

After insightsengineering/teal.data#161 modules should be refactored (all teal.modules.*) to receive teal_data object from teal.data.

Dilemmas to solve:

• what to do with tdata class in teal which is sent to data argument in teal_module$server? Should we soft-deprecate?
• Should we enable another object to work with data_merge and data_extract module which is a candidate to refactor?

[donyunardi]

Acceptance Criteria:

• Make sure the new tdata object (extension of qenv class) being pass to the modules
• Assess and update how the module received the new tdata
• Assess if the data_merge and _extract behaves appropriately, fix if not.
• Check roxygen note if any, or other documentation

We'll start with one module before hitting the rest.

On deprecation topic, we have to think about users who created their own teal modules for their projects. How this update would affect these users and what we can do about it.

[chlebowa]

qenv cannot hold reactive expressions in the code slot so filter panel code cannot be passed down to the module.
Can an S4 expert help me out here?

https://github.com/insightsengineering/teal/blob/main/R/module_nested_tabs.R#L313

[gogonzo]

qenv cannot hold reactive expressions in the code slot so filter panel code cannot be passed down to the module. Can an S4 expert help me out here?

@chlebowa object passed to the modules should be wrapped in a reactive. To be specific then - modules should get reactive returning tdata.

[gogonzo]

Closing in favour of #937