SPIKE Update UI to account for a more nuance understanding of unpublished

[maxime-rainville]

As a content author, I want to see the state of a DataObject and all its relations at a glance so I can know if I need to publish them.

Acceptance criteria

• "Stage label" on the Gridfield accounts for the record's owned relations.
• Initial "Publish" button on gridfield accounts for the record's owned relations
• SiteTree label accounts for the record's owned relations
  
• "Publish" button on CMSMain accounts for the record's owned relations
• "Cancel draft changes" button state looks up the recursive stage differ.
• Those changes do not lead to substantial performance regression even on large record list.
  • If there is a substantial performance regression, the new behaviour can be opt-in for the SiteTree and GridField List
• Projects can still use Version Snap Shot if they want to even with this change merged in.

Excluded

• Campaign admin publication labels
• Asset admin publication labels

Parent EPIC

• EPIC Publication state of parent object should reflects the state of dependant objects silverstripe-versioned#419

PRs

• ENH Updated UI for versioned objects and all its versioned relations silverstripe-cms#2912
• ENH UI updated for versioned objects and all its relations silverstripe-framework#11101
• ENH UI updated for versioned objects and all its relations silverstripe-versioned#429
• MNT New tests classes to test version tags silverstripe-frameworktest#160
• MNT Behat test for gridfield object on page silverstripe-behat-extension#259

[sabina-talipova]

While working on this task, I came across several questions regarding the behavior and use of badges.
if the parent object does not have the Versioned extension, but the child objects have this extension:

• What should the badge be if several child objects have different states. (e.g. "Draft" and "Archived"). Probably, we need some additional badge type for changes in sub objects.
• "Save" button is currently highlighted and if the user clicks on it, all child objects will be recursively published. But if the user leaves the page without clicking on the “Save” button, he receives a warning about unsaved data. This situation seems to force the user to publish the changes, but perhaps he does not currently plan to publish some of the child objects.
• This moment is more of a clarification: At the moment, if the user clicks on the “cancel draft changes” button, then all changes in the object itself and its child objects are recursively canceled. Is this correct and expected behaviour?
  I think this requires further discussion.