This can be used together with camera culling to keep nearby objects visible in
reflections, using a minimum distance within which objects are visible. It is
also useful to cull small objects far from the camera.

Empty images were implemented to expand (and eventually replace)
the background images functionalities. If we are ever to drop
background images "image empties" should support stereo/multi-view as well.

On second and third thoughts, this should have been done that way since
the begining, cases were you just delete a few data-blocks without any
serious knowledge of their usages are much, much more frequent than
cases where you are deleting thousands of data-blocks and are sure they
are not used anywhere anymore...

Own fault, but really frustrated that this topic was only raised the day
after 2.78a was released. :(

- I can not reproduce the original issue at all, so doesn't seem to
cause any regressions.

- It is really bad idea to do delayed initialization in the threaded
environment, it's a straight way to some nasty issues.

- We can't do things like this anyway because we go more granular,
meaning such a delayed initialization will fail in the case of
having several IK solvers (unless they properly accommodate to
changed bone head).

- Verified the fix with various files from Mango project and all of
them seems to work nice with new depednency graph now (old depsgraph
has some flickering, but it's not related on DEG itself, but on
an environment with lots of proxies and threaded evaluation and it
is not a new behavior).

This option makes an operator to not push a task to the undo stack if the previous stored elemen is the same operator or part of the same undo group.

The main usage is for animation, so you can change frames to inspect the
poses, and revert the previous pose without having to roll back tons of
"change frame" operator, or even see the undo stack full.

The code was templated already, so don't see big reason to have
3 versions of templated functions. It was giving some extra code
to maintain and in fact already had divergency for support of huge
image resolution (missing size_t cast in byte image loading).

Object freeing may in some kind access its obdata (in case it has some
caches e.g.), since here obdata may have already been freed, let's set
object's data pointer to NULL (probably not ideal solution, but we don't
care much, those form archipelagos of unused linked datablocks,
we nuke'em all anyway).

Also fix stupid mistake in one of own recent commits (using ID we just
freed, tsst...).

This should make it easier to sculpt in high resolutions, downside is that the new way to calculate maximum edge length is a bit less intuitive. Maximum edge length used to be calculated as blender_unit * percentage_value, now it's blender_unit / value.

Reused old DNA struct member, but had to bump subversion to ensure correct compatibility conversion. Also changed default value slightly (would have had to set to 3.333... otherwise).

Was Requested by @monio (see https://rightclickselect.com/p/sculpting/zpbbbc/dyntopo-better-scale-input-in-constant-detail-mode) and I think it's worth testing.

Enhance BKE_library_make_local() to make it much quicker in complex cases.

Basic idea is to split first loop in two, and run checks before making
anything actually local, to detect data-blocks that we can directly make
local (because we are sure they are only used by already/future local
datablocks).

This allows to avoid a lot of overhead in later 'cleanup' steps of this
function, here with barbershop shot it's four times quicker (from 190s to 48s).

We are still far from the instantaneous results of MakeLocal in 2.77,
but in that version main characters lose their connection to their
armature and remain static after makelocal, so guess new code is still
better. ;)

There are probably more optimizations possible here, but would rather
polish this area of code once we get rid of proxies, those really
make it a nightmare to work on.

If the opengl render with grease pencil is run from VSE with the current
frame outside visible frames, the render pass is wrong and the render
must be canceled because nothing to render. Related to #T49975

Culprit here was once more proxies. Think what was happening here was:
1) Both proxy and proxified armatures' PoseChannels were cleared
(needed after remapping due to Bone pointers being stored in pchans).
2) Proxy PoseChannels got rebuilt in `BKE_pose_rebuild_ex()`, which ends,
in proxy cases, by actually replacing rebuilt pchans by those from
the proxified object... which has not yet been rebuilt.

Fixed the issue by merely adding bone pointer to data copied from
original pchan into new 'from proxy' one... Sounds much, much safer and
sanier anyway, that way we can be sure bone pointer is actually pointing
to a bone of the object's armature (this is supposed to be the same
Armature datablock between proxy and proxified objects, but that may not
be always true especially during makelocal process).