Cleanup: return early in BLI_path_frame_get

Instead of making the entire body of the function conditional, it now
returns early, unindenting the entire function and preventing the reader
from searching for a non-existent `else` clause.

No semantic changes.

Fix BLI_path_frame_strip

The `BLI_path_frame_strip` function was completely broken, unless the
number of digits in the sequence number was the same as the length of
the extension. In other words, it would work fine for `file.0001.abc` (4
digit `0001` and 4 char `.abc`), but other combinations would truncate
to the shortest (`file.001.abc` would become `file.###.ab` and
`file.00001.a` would become `file.##.a`). The dependency between the
sequence number and the file extension is now removed.

The behaviour has changed a little bit in the case where there are no
numbers in the filename. Previously, `path="filename.abc"` would result
in `path="filename.abc"` and `ext=""`, but now it results in
`path="filename"` and `ext=".abc"`. This way `ext` always contains the
extension, and the behaviour is consistent regardless of whether there
were any numbers found.

Furthermore, I've removed the `bool set_frame_char` parameter, because
it was unclear, probably also buggy, and most importantly, never used.

I've also added a unit test for the `BLI_path_frame_strip` function.

Use the same string for DNA enum and CLI argument for EXR image format setting

The `--render-format` CLI option takes `EXR` and `MULTILAYER`, whereas
the DNA image format render setting uses `OPEN_EXR` and
`OPEN_EXR_MULTILAYER`. This commit adds the DNA values to the CLI
argument, so that it is possible to take the selected value from DNA and
pass it as-is to the CLI. This is used in Flamenco, for example.

The `OPEN_EXR` and `OPEN_EXR_MULTILAYER` are now aliases, so both the
existing and the new options keep working.

Reviewers: campbellbarton, brecht

Reviewed By: brecht

Subscribers: fsiddi

Tags: #bf_blender_2.8

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

Fix crash reloading images used in compositor node

Similar to what Brecht committed in
38f0d5f75af7d2f30156f4008dc5bc8d8394fbf3.

Cycles: improved rounding of sample chunks for resumable renders

When using `--cycles-resumable-num-chunks N` to render a subset of the
samples, having N close to the total number of samples causes rounding
issues.

For example, a file configured for 250 samples and 150 chunks should
have 1.6666 sample per chunk. The old code rounded this to 2 samples per
chunk, which would result in too many samples being rendered. When
rendering a single chunk this doesn't matter much, but when larger chunk
ranges are rendered with `--cycles-resumable-start-chunk` and
`--cycles-resumable-end-chunk` the rounding errors start to add up.

By multiplying with the number of chunks to render first, and only round
to integers after that, this issue is solved. In the above example,
rendering 3 chunks will correctly render 5 samples rather than 6.

When the requested number of chunks is larger than the number of samples
there will be duplicate samples (that is, sample N appearing both in
chunk M and M+1). In this case a warning is printed to stderr.

This is needed for T50977 Progressive render: use non-uniform sample
chunks.

Reviewed by: sergey

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

Alembic: C++11 doesn't need the space between '> >'

C++11 doesn't need the space between '> >' in a nested templated
declaration, so instead of `std::vector<std::pair<a, b> >` we can now
write `std::vector<std::pair<a, b> >`.

Alembic export: write curve/NURBS as mesh

It's now possible to export curves and NURBS as mesh data to Alembic.
This allows artists to do any crazy thing on curves and export the
visual result to Alembic for interoperability with other software (or
caching for later use, etc.). It's an often-requested feature.

This works around T60503 and the fixes export part of T51311.

Note that exporting zero-width curves is currently not supported, as
exporting a faceless mesh (e.g. just edges and vertices) is not
supported by the mesh writer at all.

To test, create a curve with thickness (for example extruded), export to
Alembic and check the 'Curves to Mesh' checkbox in the export options.

Reviewers: sergey

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

Alembic export: separated "writing Alembic mesh" from "writing mesh object"

I moved most of the `AbcMeshWriter` code to a new class
`AbcGenericMeshWriter`. The latter is an abstract class and does not
make any assumptions about the type of Blender object being written.
This makes it possible to write metaballs, curves, nurbs surfaces, etc.
as mesh to Alembic files.

The `AbcMeshWriter` class now is the concrete implementation of
`AbcGenericMeshWriter` for writing mesh objects.

Reviewers: sergey

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

Alembic export: fixed memory leak

If the triangulated mesh was in itself a new mesh that should be freed this
should happen before the function returns (as it only returns a single mesh,
and thus the caller can only free one).

Marked TODOs with the actual string TODO

There are some things that need to be done in Alembic for Blender 2.8 to
make all the 'visible/renderable/selected only' options work.