Revise entity state and status format and access

[sebastianburckhardt]

Three changes here:

• on the entity scheduler state: since we are maintaining the invariant (entity exists) <=> (serialized state is not null) there is no reason for defining (and serializing/deserializing) an entityExists field. Instead, just use a property.
• in client entity helpers, provide access to helper functions so external code can deserialize strings that represent EntityStatus and SchedulerState without us having to make the serialization format public. This is needed by backends that provide entity query functionality directly.
• also provide a shortcut (optimized) way to determine if an entity exists when looking at the entity status. Again, this is useful for backends implementing queries.

[davidmrdavid]

Is this change (changing DataMember to IgnoreDataMember) backwards compatible? Not immediately sure who's consuming this.

[cgillum]

This change should be backwards compatible since it should always (in theory) return the same value as before. But entities haven't been shipped/announced as a public feature of DTFx, so I assume we don't need to worry about backwards compatibility yet?

[davidmrdavid]

entities haven't been shipped/announced as a public feature of DTFx

ah, good call out

[sebastianburckhardt]

so I assume we don't need to worry about backwards compatibility yet?

I actually did design the core-entities with compatibility in mind - I was planning to switch the old entity implementation in DF to the new implementation of entities in DT core, so non-isolated users can benefit from it as well. However, that is not currently our priority - for now we just care about getting Isolated working.