Support saving no-setter properties (for example expression bodied properties)

Start with the Blip example and review EF Core's property mapping, materialization, change tracking, and save paths to determine where no-setter properties are currently excluded. Compare the requested behavior with the existing discussion and define tests that show expression-bodied properties can be saved without adding a setter, while remaining excluded from materialization when appropriate.

Note: updated to be a clear feature request based on thread discussion. Thanks!

There are good use cases for storing get-only properties (e.g., for BI tools, JSON based data feeds, and other non-EF consumers), even when those have no role in materialization.
Consider this fact oriented entity class describing a signal from a sensor:

public class Blip 
{
    public int OldState {get; set;}
    public int NewState{get;set;}
    // implying enum here but could be any EF compatible type
    public SensorAction SensorActionDetected=> Domain logic expression which resolves meaningful SensorActionDetected from raw sensor values OldState and NewState
}

After much experimentation the only reliable way I've been able to map such properties (in beta 4) is to lie and create a false setter so EF thinks it can materialize this property, such as:

    public SensorAction SensorActionDetected{ get{ return logic here} set{ ignore value } }

This implementation feels like really dirtying the domain class for the sake of EF compatibility. Future users of my data model would likely be baffled but the no-op setter.
Another option would be to make SensorActionDetected a simple auto-property without a custom getter, and set the value elsewhere, like in the set method of NewState, but this falls apart as the number of properties used in a calculation grows, you have to special case every other property setter if you can't control what order they will be populated in.
Another option would be to not include SensorActionDetected in the class and instead calculate it elsewhere such as inside SQL Server, but then you need parallel domain expert implementations of the SensorActionDetected logic everywhere Blip goes (SQL, JSON, BI Tools, etc. etc.) which is not desirable.

Please support the ability to save no-setter properties. Thanks.