XSLT: result of xsl:array-member

`xsl:array-member` returns a "parcelled" value that is subsequently used by xsl:array to form a mamber of an array. The parcelled value is currently represented as a zero-arity function. I propose to change this so the result is represented as a JNode. The disadvantage of the current approach is that the representation used by xsl:array-member doesn't correspond to the representation used by any of the standard mechanisms used for decomposing an array into its members. So it's fine for constructing a brand-new array, but not for operations like adding or removing members to an existing array. This makes it hard to find a good way of transforming arrays using template rules. With this change, we would be able to do something like ``` <xsl:variable name="$array" select="parse-json($cities)/*"/> <xsl:variable name="$subarray" as="array(map(*))> <xsl:array> <xsl:sequence select="$array[?country='UK']"/> <xsl:array-member select="{'name': 'Douglas', 'country': 'Isle of Man'}"/> </xsl:array> </xsl:variable> ``` to construct an array that combines members selected from an existing array with newly constructed members, The basic changes are: * xsl:array-member returns a parentless JNode that encapsulates the selected value. * xsl:array takes a sequence of items. Each item becomes one member of the array. If the item is a JNode, it is unwrapped to use its `jvalue` property. The `jkey` and `jparent` and `jposition` properties are ignored. This then raises the question of whether we should do the same for `xsl:map` and `xsl:map-entry`. Symmetry suggests we should. But there are a couple of complications: firstly, we have to think about backwards compatibility, since xsl:map-entry is present in XSLT 3.0. Secondly, the JNode produced by xsl:map-entry would have a key but no parent, which is a novelty in terms of the current data model, and we would need to reassure ourselves that this has no unintended consequences.