Fix crash when freeing Blender after GTests

This only frees brush_rng and random_tex_array when they were actually
previously allocated.

In a unit test (see D6246) I want to be able to partially start Blender
so that I can load a blend file. To prevent memory leaks, I also want to
be able to release memory, which currently requires calling
`BKE_blender_free()`. This unconditionally calls `RE_texture_rng_exit()`
and `BKE_brush_system_exit()`, which now crash on freeing `NULL`. This
patch fixes that.

Allocation (`BKE_brush_system_init()`) and freeing
(`BKE_brush_system_exit()`) are done asymmetrically. The allocation
functions are called from `main()` in the creator module, but the
freeing is done by `BKE_blender_free()` the Window Manager. Ideally we
symmetrise this and initialise Blender from outside the window manager
(so that the initialisation can be done without WM and Python too), but
for now I'm happy when things don't crash.

Reviewed by: sergey via pair programming

USD: Marked `USDHierarchyIterator::stage` as `const`

No functional changes.

USD: Made all fields in `USDExporterContext` const

No functional changes.

USD: No longer unpack USDExporterContext struct

The `USDExporterContext` struct contents were duplicated in the
`USDAbstractWriter` member properties, a decision which in retrospect I
don't agree with.

No functional changes.

USD: added extra comments and reordered functions

Added extra comments to explain more of the structure of the
`AbstractHierarchyIterator`, and reordered function declarations in the
header file so that it's easier to understand. Also reordered the code
in the CC file so that it has the same order as the declarations.

No functional changes.

USD: Removed unused function writer_map()

USD: Created abstract Blendfile-loading test class

This test class minimally sets up Blender so that it can load blend files
and construct a depsgraph without crashing. Note that I haven't tested this
on very complex blend files, so it may still crash when the loaded blend
file references/requires uninitialised data structures.

I also changed the USD Export Hierarchy Iterator Test to use the new test
class, and renamed it to Abstract Hierarchy Iterator Test as it doesn't
test anything USD-specific.

Merge remote-tracking branch 'origin/master' into sybren-usd

Fix crash when adding Scene variable to a driver

When a Scene variable is added to a driver, and the RNA path is still NULL,
it no longer crashes Blender.

Alembic: improved import/export of mesh normals

This commit implements the change in behaviour described in T71246.
In short:

For export, per mesh:
- Custom loop normals are defined ? loop normals are exported.
- One or more polys are marked flat ? loop normals are exported.
- Otherwise, no normals are exported.

For import, when the Alembic mesh contains:
- loop normals (kFacevaryingScope) ? use as custom loop normals, and
enble Auto Smooth to have Blender actually use them.
- vertex normals (kVertexScope or kVaryingScope) ? convert to loop
normals, and handle as above.
- no normals ? mark mesh as smooth.
- unsupported normal types (kConstantScope, kUniformScope,
kUnknownScope) ? handle as 'no normals'.

This also fixes T71130: Alembic split normal export issue

Previously the mesh flag `ME_AUTOSMOOTH` was used in conjunction with
the poly flag `ME_SMOOTH` to determine whether loop normals or vertex
normals were exported. This behaviour was hard to predict for artists,
and hard to describe in the manual. Instead, Blender now only exports
loop normals, computing them if necessary. This way, the mesh in Alembic
should always have the same loop normals as in Blender.

Maniphest Tasks: T71130

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