Rendering lists in XML may produce unexpected results

This was discovered during evaluation, and is not a case we actually need supported. It does feel unexpected and just thought it was worth mentioning.

Given the following `example.pkl` file:
```
adminIdList = List(1, 2, 3)
```

We can produce the following json file:
```
$ pkl eval -f json example.pkl
{
"adminIdList": [
1,
2,
3
]
}
```

However, when we try to produce the XML representation of this we get:
```
$ pkl eval -f xml example.pkl

123

```

This does seem unexpected and prone to mistakes, as it has a completely different meaning. There are tests expecting this behaviour, for example [input](https://github.com/apple/pkl/blob/main/pkl-core/src/test/files/LanguageSnippetTests/input/api/xmlRenderer4.pkl) and [output](https://github.com/apple/pkl/blob/main/pkl-core/src/test/files/LanguageSnippetTests/output/api/xmlRenderer4.pcf).

The following XML could be the expected behaviour for me in this particular case. But honestly, lists and XML can be tricky. How would you deal with `adminIdList = null` in this case? And how would that solution compare to that of an empty list?
```

1
2
3

```

The properties renderer just bails out for this case, which could also be reasonable.

The above has been tested using the following versions:
- `Pkl 0.25.3 (Linux 5.15.0-1053-aws, native)`
- `Pkl 0.26.0-dev+3a31188 (Linux 5.4.0-177-generic, native)`

Start with the pkl eval -f xml example and compare the existing LanguageSnippetTests fixtures: pkl-core/src/test/files/LanguageSnippetTests/input/api/xmlRenderer4.pkl and output/api/xmlRenderer4.pcf. Read the XML renderer behavior and the related properties-renderer handling, then clarify semantics for lists, null, and empty lists before changing or extending the tests.

Written by the indexing model from the issue text.