Add support for n-m relations

Nobody has claimed this yet.

Due to an existing data model setup in PostgreSQL, we received a request to add support for **N-M relations**.

In QGIS, N-M relations are implemented on top of the existing 1-N relation system. When configured correctly, QGIS adjusts the feature form UI so that the intermediate association table is hidden from the user.

```
Parent (1) ------ (N) Association/Join table (N) ------- (1) Child
```

This behaviour is controlled by the Cardinality setting in the feature form. When the relations are configured as shown above, QGIS recognises the N-M pattern and skips the association table in the UI.

As a result, users see a simplified interface where one parent feature can have multiple children, and a single child can be associated with multiple parents, without interacting with the linking table directly:

| Parent view | Child view |
|--------|--------|
| | |

---
---

**Mergin Maps side of things**

The same general approach used in QGIS could be implemented in Mergin Maps. In other words, the parent form’s relation widget would list features from the child layer directly - and the child layer would list its parents - while the association (join) table remains hidden from the UI.

At the moment, our mobile app hides the relation widget entirely whenever it detects an N-M setup. This happens on both the parent and child layers:

This behaviour is intentional:

https://github.com/MerginMaps/mobile/blob/0c7071e96449060a715317fe4e06d10c4962c399/app/attributes/attributecontroller.cpp#L306-L312

To support N-M relations properly, the main change required is to adjust how we fetch related features from the referenced (child) layer.

Currently, `RelationFeaturesModel` retrieves related features like this:

https://github.com/MerginMaps/mobile/blob/0c7071e96449060a715317fe4e06d10c4962c399/app/relationfeaturesmodel.cpp#L64

With N-M relations, the first call to `getRelatedFeaturesRequest` returns features from the association table, not directly from the child layer. Therefore, for each returned association-table feature, we need to perform an additional lookup - calling `getRelatedFeaturesRequest` (or the filter version) again - to retrieve the corresponding child features.

By merging these second-level results, we obtain the final list of child features to display in the relation widget. Essentially:
1. Fetch rows from the association table.
2. For each row, resolve the referenced child feature.
3. Combine the results into a single list for the UI.

It is a bit more work under the hood, but conceptually straightforward - and it would allow us to support N-M relations in a way consistent with QGIS.

For example, this is how it is done in QGIS: https://github.com/qgis/QGIS/blob/c755c5864983ce5cbb7f47b22cbea17ff5a9bc75/src/gui/qgsrelationeditorwidget.cpp#L624-L650

----

You can find a demo project with n-m relations setup here: https://app.dev.merginmaps.com/projects/SurveyCorp/many-to-many-relation/tree

**Next steps (to explore)**
- We need to figure out how to support adding new child/parent features (check QGIS code)
- What to do if parent/child feature is removed (anything to do in the association table?), a bit related to https://github.com/MerginMaps/mobile/issues/2315

Start with app/attributes/attributecontroller.cpp around the logic that hides N-M relation widgets, then read app/relationfeaturesmodel.cpp around getRelatedFeaturesRequest. Compare the nested relation handling with the referenced QGIS relation editor code and use the demo project to trace parent and child relations. Done should include a defined path for displaying and editing related features, including the open questions around additions and removals.

Written by the indexing model from the issue text.