Support read-only property behaviors

[ajcvickers]

Note: read-only entities is covered by issue #7586. This issue is about read/write entities with read-only properties.

The matrix of behaviors is covered by:

• Throw if value is set/changed verses ignore any set/changed value
• Insert or Update
• Property is store generated or not

For throw scenarios:

• ReadOnlyBeforeSave throws if value is set before insert
• ReadOnlyAfterSave throws if value is changed after insert
• Doesn't matter if value is store generated or not

For ignore scenarios with store-generated values

• StoreGeneratedAlways means the value set/changed will be ignored for insert or update
• Missing: way to say store-generated on update only
• Missing: way to say StoreGeneratedAlways for insert, but not update
• Missing: way to say StoreGeneratedAlways for update, but not insert

For ignore scenarios without store-generated values

• Problem with this is that after SaveChanges the database may have a different value than the client. This seems like it is usually a bad thing, and hence if value should be ignored, then it really should be made store generated.
• However, if people are okay with the value being different, and all consequences of this (fixup for FKs, etc.), then if we support StoreGeneratedAlways for all properties (changing semantics to mean ignore set/changed value) and add missing options listed above, then this would "just work".

Proposal:

• Change StoreGeneratedAlways to IgnoreValueBeforeSave and IgnoreValueAfterSave. This allows it to be set differently for inserts and updates in the same way that read-only can be.
• Respect this flag even if property is not marked store generated
• Introduce ValueGenerator.OnUpdate to support insert a value but then read-only/ignore after that

No fluent API for now, but in the future consider adding it for most common combinations.

[ajcvickers]

Design meeting notes:

• Decided to do this, although not all of it is high priority
• Would be good to combine ReadOnly... and IgnoreValue... APIs into enum, possibly obsoleting the old APIs for now
• If we add OnUpdate, then we should change the enum to be a flags enum; makes the breaking change cleaner but with higher impact, but makes it more likely that providers will react correctly to the break.