Should have been done before ahoy, sorry about that. Means 2.79 tag will
be one (no functionnal changes) commit ahead from our 2.79 builds, think
we can live with that.

Was caused by divide-by-zero in paint_stroke_integrate_overlap()
in paint_stroke.c, as identified by Bob Smith (uvwxyz).

Thanks for the report!

Threading conflict, should be safe for 2.79.

Previous fix wasn't working correct for certain compiler and CPU intrinsics
mode, causing quite some crashes.

This should be a safer fix, which is closer in behavior to previous release
but which should still fix issues with robust curve intersection.

Note: this commit seems to work as expected (also with transform
snapping etc.). However, it is rather unsafe - not enough for 2.79 at
least, unless we get much more testing on it. It also depends on three
previous ones.

Note that using a global lock here is far from ideal, we should rather
have a lock per DM, but that will do for now, whole DM thing is doomed
to oblivion anyway in 2.8.

Also, we may need a `DM_DIRTY_LOOPTRIS` dirty flag at some point. Looks
like we can survive without it for now though... Probably because cached
looptris are never copied accross DM's?

That one was doing exactly same thing as `dm->getLoopTriArray()`, no
point in having twice the same code here...

This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.

Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).

All three functions were doing exactly the same thing, simpler to only
have one in that case!

Vertices on the axis can be optionally merged,
nice for creating objects which close at the end-points.

This isn't library data.

Only the camera from View3D.localvd is used,
other pointers may be invalid.

Longer term we should probably clear these to ensure no accidents.
For now just follow the rest of Blender's code and don't access.

Need some extra checks and should be probably end up in 2.79 since that's a regression.

Baking rigid body cache was broken if some cached frames already
existed.

This is just a band aid for release, the logic need to be looked into
further.

Revert 9cd6b031, 3edc8c1f, b87d10d4 and do a better fix for T50230.

Need this in 2.79 branch as well, since build rules are based on this files.

Increased the maxx and maxy area of interest when scaling in this case.