Support for X265_BUILD >= 47

[KoolAidMan]

The X265 trunk broke the plugin yet again. This time they removed the poolNumThreads option and replaced it with a numaPools option. NumaPools works differently from the previous thread pool, as one should be able to specify processor affinity in multi-node environments. This is especially important on machines with multiple CPUs as in order to avoid a round-trip to system RAM during a load-hit-store, one could ensure processing locality and only have to bounce off the L3 cache.

Here is an explanation of how NUMA pools is supposed to work, from X265 documentation:

Comma seperated list of threads per NUMA node. If "none", then no worker pools are created and only frame parallelism is possible. If NULL or "" (default) x265 will use all available threads on each NUMA node.

'+' is a special value indicating all cores detected on the node
'*' is a special value indicating all cores detected on the node and all remaining nodes.
'-' is a special value indicating no cores on the node, same as '0'

example strings for a 4-node system:
"" - default, unspecified, all numa nodes are used for thread pools
"*" - same as default When testing this option with avidemux, it causes a crash due to what looks like an orphaned thread on destruction of X265 encoder. The default option does not...
"none" - no thread pools are created, only frame parallelism possible
"-" - same as "none"
"10" - allocate one pool, using up to 10 cores on node 0
"-,+" - allocate one pool, using all cores on node 1
"+,-,+" - allocate two pools, using all cores on nodes 0 and 2
"+,-,+,-" - allocate two pools, using all cores on nodes 0 and 2
"-,*" - allocate three pools, using all cores on nodes 1, 2 and 3
"8,8,8,8" - allocate four pools with up to 8 threads in each pool

When running against the current x265 trunk, specifying some of the documented values for numaPools (such as "*") annoyingly causes X265 to crash avidemux upon destruction of the encoder due to what is apparently an orphaned thread. For the sake of stability, we are not yet using the numaPools option; however, I have added a printf for numaPools to the debug dump in-case we decide to begin using numaPools.

The attached patch is stable and will allow us to continue building while X265 stabilizes their transition toward numaPools. Apply the patch with "patch -p1 < numaPoolsV47.diff".