Moved function declarations for modifier stack eval into BKE_modifier_calc.h.

Avoid shadowing 'mask' function parameter by a local variable.

Moved code for modifier evaluation out of DerivedMesh.c.

These files contained a confusing mix of DM code (for manipulating DMs
and various utility functions relating to these types), and the code
for evaluating object modifier stacks. These are two very distinct
areas and putting them in a single huge file doesn't promote code
clarity at all.

This commit only moves code, but does not alter any of it. This is
important for log continuity, so history of specific functions can be
clearly traced back!

Merge branch 'master' into temp_depsgraph_split_ubereval

Result struct for storing various points to DerivedMesh and deform during modifier eval.

Own function for finalizing the modifier eval result.

Use a localized ndm variable for the main dm and both possibl orco results.

Proper scoping helps understanding of the code.

Own function for setting up the DerivedMesh input for constructive modifiers.

Use a common function for deform-only modifier evaluation.

The distinction between leading and interspersed deform modifier in the
evaluation loop is superficial. The primary difference is the existence of
a derived mesh (dm), which can be handled optionally. Further conditionals
can be moved outside the loop (dyntopo would immediately cancel leading
deform eval anyway).

Simplify initialization of the deformedVerts variable.

No need to do the same thing in both code branches, the result is the same.

Moved the rather elaborate test for modifier sculptmode compatibility into own function.

Cleanup for mesh_calc_modifiers: Context and Iteration structs.

These gather most of the large number of local variables in that function,
in order to gain some clarity on their usage and scope.

Context is where immutable settings and global precomputed data is stored
during the computation. These values are initialized once and not touched
by modifiers.

Iterator struct holds the combined md/datamask pointers and some (hackish)
mutable data that gets updated during the process.

Where possible local variables have also been moved into narrower code blocks
to make the overall procedure less confusing.

Split the "uber-eval" function for object data into individual operations based on object type.

This means making a dedicated data generation function for object types that need it,
and a few utility functions for particles and extra driver evaluation (hopefully soon to be deprecated).

Remaining "uber" functions in the depsgraph should be split in a similar manner in future.

The splitting allows us to go deeper into the design of certain object types (meshes in particular)
and improve these without having to deal with all the other types.

Note on mesh vs editmesh operations:

Mesh and editmesh are calculated in separate functions. In order to get to a point
where splitting into individual modifiers makes sense, the first step is to have
two separate operations for these.

Changing edit mode does not rebuild the depsgraph, so we cannot selectively
add only one or the other at build time. Instead both operations are added, but only
one of them is actually executed. Currently this uses an internal test for the edit
mesh, but could later be controlled on the depsgraph level based on active branches.

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

Further split of the object derived mesh update into mesh vs. editmesh operations.

Mesh and editmesh are calculated in separate functions. In order to get to a point
where splitting into individual modifiers makes sense, the first step is to have
two separate operations for these.

Note that changing edit mode does not rebuild the depsgraph, so we cannot selectively
add only one or the other at build time. Instead both operations are added, but only
one of them is actually executed. Currently this uses an internal test for the edit
mesh, but could later be controlled on the depsgraph level based on active branches.

Removed pointless conditional, function call is the same in both cases.

Renamed functions a bit for simplicity.

Rationale is to use "eval" for all functions which are called directly from the depsgraph.

Split the "uber-eval" function for object data into individual operations based on object type.

This means making a dedicated data generation function for object types that need it, and a few utility functions for particles and extra driver evaluation (hopefully soon to be deprecated).

Remaining "uber" functions in the depsgraph should be split in a similar manner in future.

The splitting allows use to go deeper into the design of certain object types (meshes in particular) and improve these without having to deal with all the other types.