Exploring alternative approaches to lists

The way lists work have been tripping me up in writing the documentation. I'm documenting how they behave today, but they feel a little too magical. For example, there is different behavior based on the type of the `of` option.

Perhaps any field could be a list. I could do something like this:

```js
{
fields: {
// ...
tags: { type: 'reference', of: Tag, list: true }
}
}
```

If we were to do that, it would also be interesting to consider if any field could then be polymorphic. For example, what if I wanted a list of strings or numbers?

```js
{
fields: {
// ...
someListField: { type: ['string', 'number'], list: true }
}
}
```

This polymorphic field type could be interesting to consider outside this context, too. Perhaps any field (not just a list) could be one of multiple types and still be valid.

L’issue non indica file, test o punti di ingresso. Inizia esaminando il comportamento attuale delle liste nella documentazione, quindi chiarisci l’ambito previsto per i campi lista arbitrari e i tipi polimorfici; il lavoro è completo solo quando viene specificato un approccio concordato.

Scritto dal modello di indicizzazione a partire dal testo della issue.