Fix: re-do versioning code for FCurve extremes and Collection colors

Bump Blender subversion from 4 to 5, and re-execute some versioning code.

Because of a mistake in the versioning code (corrected in rB1a4fc6dcd67b),
some of the versioning code didn't run in certain cases. This subversion
bump ensures that this code is still run.

Cleanup: move versioning code into "until next bump" block

A bit of versioning code was not part of the "Versioning code until next
subversion bump goes here" block, making the diff of an upcoming bump
harder to read. This commit just moves the code to the appropriate spot.

No functional changes.

Alembic export: write custom properties

Write custom properties (aka ID properties) to Alembic, to the
`.userProperties` compound property.

Manifest Task: https://developer.blender.org/T50725

Scalar properties (so single-value/non-array properties) are written as
single-element array properties to Alembic. This is also what's done by
Houdini and Maya exporters, so it seems to be the standard way of doing
things. It also simplifies the implementation.

Two-dimensional arrays are flattened by concatenating all the numbers
into a single array. This is because ID properties have a limited type
system. This means that a 3x3 "matrix" could just as well be a list of
three 3D vectors.

Alembic has two container properties to store custom data:
- `.userProperties`, which is meant for properties that aren't
necessarily understood by other software packages, and
- `.arbGeomParams`, which can contain the same kind of data as
`.userProperties`, but can also specify that these vary per face of a
mesh. This property is mostly intended for renderers.

Most industry packages write their custom data to `.arbGeomParams`.
However, given their goals I feel that `.userProperties` is the more
appropriate one for Blender's ID Properties.

The code is a bit more involved than I would have liked. An
`ABCAbstractWriter` has a `uniqueptr` to its `CustomPropertiesExporter`,
but the `CustomPropertiesExporter` also has a pointer back to its owning
`ABCAbstractWriter`. It's the latter pointer that I'm not too happy
with, but it has a reason. Getting the aforementioned `.userProperties`
from the Alembic library will automatically create it if it doesn't
exist already. If it's not used to actually add custom properties to, it
will crash the Alembic CLI tools (and maybe others too). This is what
the pointer back to the `ABCAbstractWriter` is used for: to get the
`.userProperties` at the last moment, when it's 100% sure at least one
custom property will be written.

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

Reviewed by: sergey, dbystedt

Avoid breakage when there are no custom properties to be written

Tweaks and adjustments and abstractions and generalisations and tests

Always flatten arrays of arrays

Remove debug prints

Generic int/float/double matrix support

Support for matrices of type double

Alembic export: write scalar custom properties

Write scalar custom properties as array properties to Alembic. This is
also what's done by Houdini and Maya exporters, so it seems to be the
standard way of doing things.

Seems to work ok'ish if I look at it via `usdcat`.