ed_undo refactor: split/remove `ed_undo_step_impl`.

This function was doing too many things, with behaviors fairly different
depending on its input parameters. This was making the code fragile and
hard to follow.

Split it in three:
* `ed_undo_step_pre` does the common actions before we actually undo
data.
* `ed_undo_step_post` does the common actions after we have undone/redone
data.

Then, `ed_undo_step_direction`, `ed_undo_step_by_name` and
`ed_undo_step_by_index` do their actual specific actions, with their own
logic.

Note: Since the actual behavior of those three funtions is fairly
different (the first only undo/redo one effective step, the second is only
supposed to **undo** //before// given named step, and the third actually
undo/redo until given indexed step become active), we could also find
better names for those. right now, it sounds like they are doing the
same thing, with just different ways to specify the target step.

Note: This is part of on-going refactor work on undo system, see T83806.

Differential Revision: https://developer.blender.org/D10112

LibOverrides: First stage of detection of 'need resync'.

We can fairly easily detect some resync-needed cases when applying the
overrides operations on a Pointer RNA property.

This should cover all cases where an existing override's ID pointer is
changed in its linked data.

We still have to add code to detect when a not-yet-overridden linked ID
needs to become overridden (because its relations to other data-blocks
changed in a way that requires it).

LibOverride: refactor of relationships handling in library overrides.

First step towards a better handling of relationships between IDs in
override context, especially when a resync is needed.

First, introduce a new flag to override operations,
`IDOVERRIDE_LIBRARY_FLAG_IDPOINTER_MATCH_REFERENCE`, for ID pointers.
It keeps track of whether an RNA ID pointer has been kept to its
'natural overriden ID' (in override hierarchy context), or has actually
been re-assigned to some other data-block.

Second, refactor how we deal with relationships between IDs in override
hierarchy code, especially in resync case. This will fixe several cases
listed in T83811, especially the case where an ID pointer to an existing
override needs to be updated to a new one due to a matching change in
linked data.

Merge branch 'blender-v2.92-release'

Fix UI message typo in own previous commit.

//sigh//

Merge branch 'blender-v2.92-release'

Fix UI messages.

Avoid sticking words together when it's not absolutely necessary.

Fix crashes from recent refactor rB131a758b6f88.

Much better to add a relation entry for all IDs, even if they are not
connected to any other ID.

Refactor BMain relations temp data.

`bmain.relations` is used to store temp data of relations between IDs,
to speed-up some complex processes heavily relying on such information.

Previous implementation was failry unclear/confusing, and required a
not-so-nice hack to 'tag' some ID as processed.

New code changes as such:
* Using `from`/`to` naming (instead of `user`/`used`).
* More clear separation between `to` `id_pointer` and `from` one,
using an union instead of hacking around difference between `ID *` and
`ID **` pointers.
* Adds storage of `session_uuid` informations (mainly useful as
debug/ensuring proper consistency of data currently).
* Adds a structure per ID in the mapping. This enables possibility of
storing tags (and potentially more data in the future) per-ID,
without polluting the IDs themselves with very short-life info.

Differential Revision: https://developer.blender.org/D10164

LibOverride: Add an 'post apply' callback to IDTypeInfo.

Currently this is needed to properly tag PointCache's for info update
(fixes an issue reported in T82503).

Suspect we may need this in more cases in the future though, RNA
assign/update processes are not always 100% enough to deal with
complicated corner cases.