Amp4Email nested lists idea

## 🚀 Feature Request

### Problem
I've noticed that some of the amp4email codebases I've looked at encounter and need to compensate for limitations around nesting amp-lists. for example, a list of discussions each containing a list of comments

I think one side effect of this problem is that it stresses the use case for single item lists. When you can't define nested lists you tend to need to flatten your data in creative ways. You focus your UX on the most important list, and join in individual data points as needed

Not filling this feature request seems to be because of risks on self referencing lists, and potentially also rendering nested mustache templates and/or amp-lists

### Solution
Allow amp-list to reference a data source via items, or a reserved src format like how binding an amp-list to an amp-state works. This solution just focuses on what I think is an easy and understandable way to define nested amp-list syntax as someone developing with amp, I'm guessing rendering nested lists and their bindings will be the limiting factor and more important question...

Consider binding amp-list xhr response to amp-state under the hood to move enforcement of json structure / self referencing json nestings to that silo, and also potentially merge nested amp-lists to a similar flow as binding an amp-list with an amp-state, the child amp-list would treat its parent amp-list's internal amp-state as its src and use `items="..."` to drill down a level, keeping the prevention of recursive json structures under the responsibility of amp-state

Nested lists could use slightly different syntax

xhr endpoint (https://www.example-api.com/nested) returns json - an array of discussions, each containing who their assigned to, if their resolved, and all comments made in the discussion
```
{discussions: [
{
assignedTo: {
fullName: "",
role: ""
},
comments: [],
isResolved: true
},
...
]}
```

would use amp syntax:

```

### Alternatives
Handling all nestings via a combination of flattening & creativity in the json response and in the amp implementation

```

The alternative is shorter at the top level but would be longer at lower levels within each list, and harder to follow the flow of