Allow read-resource users to specify that attrbutes should be organized by attribute group

Currently the read-resource output reports all attributes in a flat list, so the relationship between any attributes that are in an attribute-group is lost.[1] But, the output of read-resource an already be customized in various ways via operations parameters, so I see no reason we couldn't add a param to customize the representation of attributes.

An 'attributes-by-group' param could be used to trigger moving away from the flat list. Ungrouped attributes would appear first, followed by the groups. Then there is a node named "attribute-group", the children of which are the group names, and the children of each group name are its attributes.

This somewhat makes the term "attribute-group" a reserved word. To help mitigate that, if any ungrouped attribute or resource child type is named "attribute-group" (unlikely but possible), then the attributes for that resource will not be reported in grouped manner the response includes a warning header stating this.

A transformer would need to be used with mixed domain. I think it would have to reject the op (or perhaps add a response warning header), as I don't see how we could reliably transform an unsorted response from a slave that didn't understand this param. The DC would not have reliable information to know what the groups are on the slave (which may have a different model than the DC.) THE VERY FIRST STEP ON THIS MUST BE SORTING OUT THE MIXED DOMAIN QUESTION. If we can't sort that in an acceptable manner, we won't implement this.

Conceptually the same kind of thing could be applied to read-resource-description, but that is not in the scope of this RFE. The r-r-d already reports the attribute-group info for each attribute, so the value is less, while including r-r-d would basically be doubling the amount of work involved.

[1] I believe the sorting of the flat list is currently by group, but since the group names are not shown that representation is not visually clear, and there's a JIRA to fix the resulting confusing output by always sorting alphabetically.