Clarify the use of ETags for Avoiding Update Conflicts

Make clear that EntityCollection/$ref and SingleEntity/$ref are intentionally allowed to return an ETag. EntityCollection/$ref (where EntityCollection is an entity set or collection-valued navigation path) may have an (own) ETag returned in the ETag header which changes if the list of references changes, i.e. a reference is added or removed. SingleNavigation/$ref (where SingleNavigation is a single-valued navigation path) may have an ETag which represents the identity of the related entity. If the relationship is changed to point to a different OData entity, the ETag MUST change. Note: the ETag for an entity reference (i.e. EntitySet(key)/$ref) can never change. In JSON, if an object contains an etag (or other control information other than type) then it is a representation of the object, not an entity reference. so: {"@id":"people(1)"} is an entity reference to the resource in the people entity set with the key value 1, where: {"@id":"people(1)","@etag":"xyz123"} is a minimal representation of the resource (not the reference), just as {"@id":"people(1)","name":"maggie"} is a minimal representation of the resource. So, if {"@id":"people(1)","@etag":"xyz123"} is returned, the etag refers to the person (and not the reference) and changes if any properties of the person changes.