Merge branch 'master' into outliner-cpp-refactor

Merge branch 'master' into outliner-cpp-refactor

Cleanup: Split header for Outliner tree building into C and C++ headers

It's odd to include a C++ header (".hh") in C code, we should avoid that. All
of the Outliner code should be moved to C++, I don't expect this C header to
stay for long.

Cleanup: Rename Outliner "tree-view" types to "tree-display" & update comments

"View" leads to weird names like `TreeViewViewLayer` and after all they are
specific to what we call a "display mode", so "display" is more appropriate.

Also add, update and correct comments.

Cleanup: Follow C++ code style for new Outliner building code

* Use C++17 nested namespaces.
* Use `_` suffix rather than prefix for private member variables.

Also: Simplify code visually in `tree_view.cc` with `using namespace`.

Cleanup: General cleanup of Outliner Blender File display mode building

* Turn functions into member functions (makes API for a type more obvious &
local, allows implicitly sharing data through member variables, enables order
independend definition of functions, allows more natural language for
function names because of the obvious context).
* Prefer references over pointers for passing by reference (makes clear that
NULL is not a valid value and that the current scope is not the owner).
* Reduce indentation levels, use `continue` in loops to ensure preconditions
are met.
* Add asserts for sanity checks.

UI Code Quality: Convert Outliner Blender File mode to new tree buiding design

See https://developer.blender.org/D9499.

Also:
* Add `space_outliner/tree/common.cc` for functions shared between display
modes.
* Had to add a cast to `ListBaseWrapper` to make it work with ID lists.
* Cleanup: Remove internal `Tree` alias for `ListBase`. That was more confusing
than helpful.

Cleanup: Put Outliner C++ namespace into `blender::ed` namespace, add comments

Also remove unnecessary forward declaration.

Fix possible null-pointer dereference in new Outliner tree building code

Cleanup: Remove redundant parameter from new Outliner tree building code

Merge branch 'master' into outliner-cpp-refactor

Cleanup: Comments & style improvements for new Outliner C++ code

* Add comments to explain the design ideas better.
* Follow code style guide for class layout.
* Avoid uninitialized value after construction (general good practice).

UI Code Quality: Use C++ data-structures for Outliner object hierarchy building

* Use `blender::Map` over `GHash`
* Use `blender::Vector` over allocated `ListBase *`

Benefits:
* Significantly reduces the amount of heap allocations in large trees (e.g.
from O(n) to O(log(n)), where n is number of objects).
* Higher type safety (no `void *`, virtually no casts).
* More optimized (e.g. small buffer optimization).
* More practicable, const-correct APIs with well-defined exception behavior.

Code generally becomes more readable (less lines of code, less boilerplate,
more logic-focused APIs because of greater language flexibility).

UI Code Quality: General refactor of Outliner View Layer display mode creation

* Turn functions into member functions (makes API for a type more obvious &
local, allows implicitly sharing data through member variables, enables order
independend definition of functions, allows more natural language for
function names because of the obvious context).
* Move important variables to classes rather than passing around all the time
(shorter, more task-focused code, localizes important data names).
* Add helper class for adding object children sub-trees (smaller, more focused
units are easier to reason about, have higher coherence, better testability,
can manage own resources easily with RAII).
* Use C++ iterators over C-macros (arguably more readable, less macros is
generally preferred)
* Add doxygen groups (visually emphasizes the coherence of code sections,
provide place for higher level comments on sections).
* Prefer references over pointers for passing by reference (makes clear that
NULL is not a valid value and that the current scope is not the owner).

UI Code Quality: Start refactoring Outliner tree creation (using C++)

The Outliner tree creation was very messy and hard to follow. Hardcoded display
type checks are scattered over many places.
This introduces a new abstraction "tree-view" to help constructing and managing
the tree for the different display types (View Layer, Scene, Blender file,
etc.).

Idea is to have an abstract base class to define an interface
(`AbstractTreeView`), and then subclasses with the implementation of each
display type (e.g. `TreeViewViewLayer`, `TreeViewBlenderFile`, etc). The
tree-viewer is kept alive until tree-rebuild as runtime data of the space, so
that further queries based on the display type can be executed (e.g. "does the
view support selection syncing?", "does it support restriction toggle
columns?", etc.).

I may still change the names a bit, not sure yet if "tree-view" is the right
term for this helper.