ContentModerationStateInterface additions

This is an interesting one. I don't really feel like the ContentModerationState should be the go-to way of interacting with the moderation states, all of that should be done through the computed field if possible. Adding methods to the interface would encourage it as a part of the public API. It raises the question if that whole entity type should be @internal. Or at least there should be a review of the methods to see what should be internal or not, getCurrentUserId seems like a candidate.

Is this use case based on the result of an entity query, or something similar? Maybe we can provide some wrapper around these kind of queries to abstract the details of the underlying entity away. I wonder how hard it would be to make entity query work to join against content_moderation_state so you could simply go ->condition('moderation_state', 'draft'); on a node entity query for example.

Also, you can call protected methods on objects if the method doing the calling is on the same class the protected method is on, even if the entity !== $this.

I mostly agree with #4, content_moderation_state entity shouldn't be where you go to interact with moderation states, and maybe we should mark it as @internal.

The content_moderation_state entity is sometimes useful when wanting a list of all "archived" entities across different entity types, which I hope we'll be able to do in Views, but other than that you should come via the computed moderation_state field.

Maybe we should remove the ContentModerationStateInterface?

@jhedstrom - That is the best way, Workbench Moderation used to fire an event, but when we switched to use a content entity for storage there was no need for the event as we have a hook. So I guess for this use case it kinda makes sense.

@jhedstrom, how would you feel about doing something like #2873287: Dispatch events for changing content moderation states instead? It would be part of the effort to ensure people don't have to understand and interact with the ContentModerationState entity directly. I think it'll be marked @internal at some point and we're already doing things like #2779931, which deny all access to it for CRUD purposes.