Clarify Referential Constraints have UpdateRule=Cascade semantics

The current specification defines referential constraints that specify properties of the dependent entity must be the same as the corresponding properties of the principle entity. This is similar to a foreign key in a database which specifies that the property of a dependent row must match the (typically primary key) properties of a row in the principle table. Foreign keys in a database are defined through Referential Constraints which have a DeleteRule and an UpdateRule that specify what happens to dependent rows when the principle row is deleted or updated.

In OData, the referential constraint implicitly includes the navigation property which enforces the uniqueness constraint required in relational databases. This allows us to define referential constraints on sets of properties that may not be unique outside of the implicitly added to 0..1 navigation property.

In OData we also define an OnDelete rule that specifies what happens if the principle entity is deleted. However, we don't define an UpdateRule. We also don't say what happens if the client tries to update a dependent property (which would be an error if they didn't at the same time change the navigation property to point to a principle entity with the same value).

The reasonable behavior would be for updates to the dependent properties to be ignored by the service and for updates to the referenced property in the primary entity to "cascade" to the dependent entities. This fits well with the denormalization scenario we were trying to support in allowing the referential constraint to support non-key properties. We even imply this strongly in the insert case by saying that dependent properties may be omitted and must be ignored by the service in inserting a new entity, we just are not as clear in the updating section, when we talk about omitting "key and non-updatable properties" that this includes dependent properties defined within a referential constraint.