Fix second issue introduced in refactoring/cleanup of weighted normals.

'degenerated too short normals' check was probably a bit too aggressive,
moved it back to more common 1e-6 value.

Fix weighted normals modifier sometimes affecting actual mesh.

Same issue & same fix as with edit normals modifier some times ago...

Merge branch 'master' into soc-2017-normal-tools

Create README.md

Changed rotation calculation in rotate_normal

Merge branch 'master' into soc-2017-normal-tools

Moar cleanup.

Cleanup some leftover after recent refactor.

Merge branch 'master' into soc-2017-normal-tools

Heavy refactor of weighted normals code, especially 'keep sharp' part.

Before, 'keep sharp' was bsically:
* Overwriting everything just computed by 'single nor per vertex' code,
leading to a nice share of computations being tossed to nowhere.
* Re-implementing most of core clnor computaion code, only skipping all
'sharp edge' cases but the one defined by shapr edge tags. This was not
only bad for code maintenance and (reasonable) simplicity, it was also
introducing inconsistencies in how we define sharp edges, since
everwhere else in code we take into account sharp edge tag, flat face
tag, and 'smooth threshold' value (aka split angle) of mesh.

At first I though 'keep sharp' would need its own totally separated code
path, but thanks to some data structure tricks, it was possible to merge
most of both cases into single code. So this commit:
* Heavily factorizes and simplifies code, especially the 'keep sharp' case.
* Makes use of clnor spaces as generated by core BKE code to define
'smooth fans' that should have the same weighted normals, just like
anywhere else in Blender.

Note that since code is now using same functions in all cases, it also
naturally brings back vgroup support in keep_sharp case.

Also, this has been a fairly involved change, basic testing seems to be
OK, but more would be welcomed here. :)

Add clnor_spaces counter and opaque userdata pointer to clnor spaces.

Those will help with weighted normals modifier incomming refactor.

Merge branch 'master' into soc-2017-normal-tools

Partially revert "Fixed vertex groups not respected with keep sharp in modifier."

This reverts some changes from commit a7a4beecb208d12a00d550e3ebf4e2a37730fa6b.

Fixed vertex groups not respected with keep sharp in modifier.

Also fixed some other trivial issues.

Change 'face strength' values.

WARNING! this will break files saved with this branch and using face
strength feature (no crash or data corruption, but face strength values
will become invalid and will produce weird results)!

Rationals for this change are:
* Having strength values in natural order simplifies existing code
already, not to mention any future potential addition to strengthes.
* Now, code will work as-is, even if we decide to add more stength
values in the future.

Cleanup: use MEM_[cm]alloc_arrayN as needed, instead of MEM_[cm]allocN.

New memory allocator was added a few months ago as an attempt to make
our memory management more secure, still have to go over rest of this
patch's code for same thing. ;)

Serious refactor, adding common data struct, some factorizing...

We now pass most common parameters to processing functions using a
single struct, this is much cleaner.

Also, factorized code aggregating poly nors into vertex nors in new
aggregate_vertex_normal function, and optimized expensive powf calls
(exponential inverse weight...) by computing once and caching most
common values (since weight is static all-over processing, and nearly
all vertices will only have a few faces or loops using them...).

Note that am still very unhapy with 'keep sharp edges' case, that one
seems to copy a lot of code we already have in BKE_mesh_evaluate, and
(if I followed code correctly) recompute everything, essentially
ditching the whole first computations of weighted normals!

Fix broken 'is vertex in vgroup' check.

Also, better to avoid binary XOR on booleans, you never know how those
are actually stored internally (or how they were generated), and may get
surprising results depending on compiler etc., though with modern
compilers I?d expect this to be safe now?

More cleanup and optimizations.

Style and naming, arg positons (all loops data together, etc.),
const values and args, and so on...

Also, avoid allocating unused memory, avoid extra loops when possible, etc.

Minor cleanup and silplification/optimizations...