WIP
---------------
General Idea
==========
System overrides is currently a concept applied to ID pointer properties, a way to say 'this override data is different than its linked reference, because override system needs it, not because the user defined it as different'.
E.g. if, in an override, a RNA property points to a different ID than in the reference linked data, but that ID is an override of the one pointed to in the linked data, then this is a system override.
The idea of this tasks is to extend this principle to entire IDs, which would then behave from the user point of view essentially as non-editable, linked data.
Typical usecase would be the collections of a character. They need to be overridden so that the key objects of the character can also be overridden and edited/animated, but user should not actually ever manually edit those collections.
Behavior of System Overrides
=======================
* From a user perspective, they behave similar to linked data.
** Their properties are shown greyed out/un-editable in the UI.
* System Overrides can become editable (user) overrides from the Outliner.
** Some ID types could also automatically switch to user overrides when their properties get edited? This has UI/UX design issues though.
** Editable overrides cannot become system overrides directly (except from RNA API), this is automatically handled when users chose to 'delete' them (if the override is not using any other override, it is deleted, otherwise it is reset and turned back into a system override).
* 'Override from ID widget' will now perform a hierarchy override instead of a single override.
* What becomes a system override when creating an override hierarchy:
## From 3DView operator:
*** All collections are system overrides.
*** If applied on Empty-instanced linked collection, everything but armature objects are system overrides.
*** If applied on selected objects from a viewlayer-instanced collection, everything but those selected objects are system overrides.
## From Outliner:
*** Everything but the selected IDs are system overrides.
## From ID widget:
*** Everything but the selected ID are system overrides.
## From RNA API:
*** Everything are system overrides.
Tasks
=====
[x] Decide a name to expose to user: Keep 'System Overrides' ? Or find something less 'technical', like maybe 'Inactive Overrides' ? 'Hidden Overrides' ? 'Disabled Overrides"? //NOTE: Would apply to both new ID system overrides, and existing IDPointer RNA properties system overrides.//
** Proposed new name for UI: Editable Overrides / Non-Editable Overrides (respectively for 'user overrides' vs. 'system overrides').
** NOTE: Overrides properties that are driven or animated are still considered as 'editable' then.
[x] Define an icon for system overrides. - use grayed-out library override icon for now. {rB9394d455af43}
//Very early tentative idea: transform the underlying link into a key: {F12868484} Could also try to add a lock, but think it would make the icon overloaded? //
//Another possibility is to simply use the current liboverride icon, but in a 'grayed out' version, similar to what is done with indirectly linked libraries?//
[x] Define & implement low-level technical aspect (most likely simply one new liboverride flag). {rB5adcf6c85e4c}, {rBd7c802c25f7e}, {rB6cc9ba94b78c}
[x] Define and implement default behavior (what is by default a system override vs a user-editable override).
[x] ~~We probably need some sort of 'overridable anyway' properties, e.g. visibility etc. flags of collections?~~ Think re-using the existing `PROP_LIB_EXCEPTION` for this purpose is fine too... At least for now.
[] Implement hierarchy override from ID widget.
[x] Update various low-level checks to define 'generic common Blender behavior' regarding those system overrides (maybe refactor or extend the `ID_IS_LINKED` usage?). {rB5596f79821ca}
[] Hook this new concept into the Outliner UI.