Changes

restrict: reorder children when modified
If we first bit of the cpuset of some children increases during
restrict(), these children might become out-of-order.
Example:
 Core P#0
   PU P#0
   PU P#2
 Core P#1
   PU P#1
   PU P#3 If restrict() removes PU P#0, Cores must be swapped because
of their updated cpusets.
In v2.x, reordering might also be needed for memory children but it's
so unlikely and harmless that we don't do it yet.
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>

tests/restrict: check that we reorder properly when needed
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>

lstopo: fix --children-order parsing
It was removed from "layout" to "order" right before push, and actually
broke there.
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>

synthetic: initialize a level arity when it's entirely ready
arity=0 is used as a marker for the end of the array of synthetic
levels, so only initialize it to > 0 when everything else is ready in
the level structure.
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>

tests/restrict: fix a synthetic description
Introduced in 03ac9b28b4882abb2dd12247ce37b97a103db6c9
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>