health-check: An automated performance reporting tool

This new target will generated a bootable image that will compute some
system tests to estimate it's efficiency and health status.

A series of raw numbers will be generated and reported inside an
extended hw.py file.

This patch add the required makefile targets, the testing suite (make
health-check).

health-check is today only reporting the cpu performance by using
sysbench.

A typical output is like the following:
('cpu', 'physical_0', 'physid', '1'),
('cpu', 'physical_0', 'cores', '2'),
('cpu', 'physical_0', 'enabled_cores', '2'),
('cpu', 'physical_0', 'threads', '4'),
('cpu', 'physical', 'number', 1),
('cpu', 'logical', 'number', '4'),
('cpu', 'logical_0', 'bogomips', '5187.90'),
('cpu', 'logical_0', 'cache_size', '3072KB'),
('cpu', 'logical_0', 'loops_per_sec', 561),
('cpu', 'logical_1', 'bogomips', '5187.90'),
('cpu', 'logical_1', 'cache_size', '3072KB'),
('cpu', 'logical_1', 'loops_per_sec', 561),
('cpu', 'logical_2', 'bogomips', '5187.90'),
('cpu', 'logical_2', 'cache_size', '3072KB'),
('cpu', 'logical_2', 'loops_per_sec', 553),
('cpu', 'logical_3', 'bogomips', '5187.90'),
('cpu', 'logical_3', 'cache_size', '3072KB'),
('cpu', 'logical_3', 'loops_per_sec', 542),
('cpu', 'logical', 'loops_per_sec', 1604)]

Reporting is spliting physical cpu (sockets) and logical one (thoses
seen by Linux).

Detailed information about physical are only available if seen by lshw.
Bogomips & cache_size are taken from the /proc/cpuinfo while the
loops_per_sec are computed by running sysbench for 10 seconds.

Note that loops_per_sec are reported for
- each logical processor by running binding sysbench on the selected processor but also for
- all logical processors at one time by running sysbench with num-threads = the
  number of logical processors.
health-check: Adding memory performance report

This commit is using sysbench to analyze the performance of the memory
by checking several block size and from all the logical CPUs.

This could be useful to detect a processor that doesn't reach the memory at the proper speed.
NUMA systems could be affected by such behavior.

This component will help at discovering this effect.

A typical output is like :
 ('cpu', 'logical_0', 'bandwidth_1K', '3017'),
 ('cpu', 'logical_0', 'bandwidth_4K', '7037'),
 ('cpu', 'logical_0', 'bandwidth_1M', '10400'),
 ('cpu', 'logical_0', 'bandwidth_16M', '8859'),
 ('cpu', 'logical_0', 'bandwidth_128M', '9042'),
 ('cpu', 'logical_0', 'bandwidth_1G', '9012'),
 ('cpu', 'logical_1', 'bandwidth_1K', '2718'),
 ('cpu', 'logical_1', 'bandwidth_4K', '7048'),
 ('cpu', 'logical_1', 'bandwidth_1M', '10670'),
 ('cpu', 'logical_1', 'bandwidth_16M', '8764'),
 ('cpu', 'logical_1', 'bandwidth_128M', '8716'),
 ('cpu', 'logical_1', 'bandwidth_1G', '8987'),
 ('cpu', 'logical_2', 'bandwidth_1K', '3066'),
 ('cpu', 'logical_2', 'bandwidth_4K', '6913'),
 ('cpu', 'logical_2', 'bandwidth_1M', '10502'),
 ('cpu', 'logical_2', 'bandwidth_16M', '8884'),
 ('cpu', 'logical_2', 'bandwidth_128M', '8986'),
 ('cpu', 'logical_2', 'bandwidth_1G', '8853'),
 ('cpu', 'logical_3', 'bandwidth_1K', '3049'),
 ('cpu', 'logical_3', 'bandwidth_4K', '6969'),
 ('cpu', 'logical_3', 'bandwidth_1M', '10423'),
 ('cpu', 'logical_3', 'bandwidth_16M', '8878'),
 ('cpu', 'logical_3', 'bandwidth_128M', '8927'),
 ('cpu', 'logical_3', 'bandwidth_1G', '8663'),
 ('cpu', 'logical', 'bandwidth_1K', '3010'),
 ('cpu', 'logical', 'bandwidth_4K', '7000'),
 ('cpu', 'logical', 'bandwidth_1M', '10580'),
 ('cpu', 'logical', 'bandwidth_16M', '8704'),
 ('cpu', 'logical', 'bandwidth_128M', '8838'),
 ('cpu', 'logical', 'bandwidth_1G', '8941')
health-check: Adding missing file

Ooops.
health-check: Reporting DDR timings

As per some code from Cyring (http://code.cyring.fr/FTS/), it's possible
to get the DDR timing on some Intel processors.

This could be really useful to compare DDR timing from one node to
another to detect some different set of DDR memory banks.
health-check: Being verbose on stderr

By printing to stderr, it helps the main init to report the current
status while not flooding the resulting .py file.
health-check: Switching CPU benchmark to 5 seconds

5 seconds is enough to get a good overview of the CPU performance.
Dividing by 2 the time needed to get CPU perf makes the global process
faster.
health-check: Override the default resolv.conf

This is needed when moving your build machine from one network to
another.