Merged TEncCfg into Encoder.  A few VUI tweaks and fixes.

--HG--
extra : rebase_source : dcbcda7022ced8f518c25cb6aab9b5067f5d010b
cmake: TEncCfg.h is caput

--HG--
extra : rebase_source : e945629f8cb4423e22e5c5174f0be88b154f6833
api: move VUI settings into vui sub-struct of x265_param

--HG--
extra : rebase_source : bcfc0853c287d7dfd85fb274132264e67e274fc6
api: move x265_ssim() to be an internal function, give a more descriptive name

This function really shouldn't have been a public function, and it was never
added to the exports list.

--HG--
extra : rebase_source : 1392e11528c7e6cee30ec0da7c7f15fbeb5f3b4c
api: move cpuid to x265_param, same as x264
cli: do not call x265_setup_primitives() from printVersion()

It now leads to redundant console output and it was interfering with --asm
command line arguent functionality
cmake: dllmain is no longer necessary since use of object libraries
cmake: bump X265_BUILD to 8, many API changes

These changes should be mostly harmless, I don't expect many API users have used
the VUI fields yet, so a recompile against the new x265.h should be sufficient.
weight: use correct round value for denom 0 [CHANGES OUTPUT]

The denom -without the intermediate bit-depth factor applied- must be compared
with zero, else the output of weight_pp will not match the real output of pixel
weighting. This was done wrong in two different ways in three different places
weight: do not attempt chroma weights if luma was not weighted [CHANGES OUTPUT]

This heuristic seems to improve a number of clips, particularly when chroma
distortion is not considered in mode decision.  This could cause some odd colors
to be encoded, particularly noticable with large blocks.
weight: simplify and remove redundant logic
primitives: prevent multiple setup calls from reiniting primitive table

We don't want the function table to change in the middle of an encode. Improve
logging so that --asm <SMALLINT> which does not result in any bitmap matches
still reports "none!"