Use case for `xf:copy` attributes support

All,

Here is a use case for `xf:copy` which we can support if we support
handling attributes.

Let's say we an XML representation which proposes a discriminated union
based on a `type` attribute. We have, in the data, either:

    <label type="PredefinedButtonLabel"/>

or:

    <label type="CustomButtonLabel">
        <name type="object">
            <values type="object">
                <en>Custom Button</en>
            </values>
        </name>
    </label>

If `xf:copy` supports attributes, then I can write successfully write my
selection as follows:

    <xf:select1 ref="label" appearance="full">
        <xf:item>
            <xf:label>Predefined</xf:label>
            <xf:copy ref="xf:attribute('type', 'PredefinedButtonLabel')"/>
        </xf:item>
        <xf:item>
            <xf:label>Custom</xf:label>
            <xf:copy
                ref="
                    xf:attribute('type', 'CustomButtonLabel'),
                    if (@type = 'CustomButtonLabel') then
                        *
                    else
                        instance('my-custom-button-label-template')"/>
        </xf:item>
    </xf:select1>
    <xf:input ref="label/name/values/en"/>

(Here I use the `xf:attribute()` function but we could also point to
attributes in a template instance.)

The `if ... then ... else` pattern in the second `xf:copy` is there so
that, in case the user has already selected a `CustomButtonLabel` and
edited the value of the button label (here "Custom Button" initially),
there will still be an exact match and the item can show as selected.

The `xf:copy` logic must:

- to determine a match: compare the attributes in addition to the other
nodes returned by `xf:copy/@ref`
- to deselect: remove the matching attributes of the item being deselected
- to select: add the attributes of the item being selected

So really it's not much harder than not supporting attributes.

-Erik