add gitignore config

This is required since client tests are now in separate git repo.
sparse: update sparse test

- Update source: sparse-2006-04-28 -> sparse-2013-06-26
- Store number of errors and warnings as keyvalue, useful for later analysis
- Add configurable build target, usefull for subsystem checking

Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Add new test module smatch - New kernel source analizer testsuite

Smatch is source analizer similar sparse with number of usefull features
- catch undefined variables
- resource leackage
- spinlock/mutex leackage

After the compile finishes logs stored to smatch_log and smatch_error
key values = [ 'warnings', 'errors' ]

Original smatch log:
Smatch - The Source Matcher, brought to you by the good folks at KernelJanitors.

Smatch has been completely rewritten in C and now uses sparse as a C parser
instead of gcc as a C parser. The new URL is http://repo.or.cz/w/smatch.git.
If you are using smatch against the kernel the command is:
        make CHECK="~/path/to/smatch/smatch -p=kernel" C=1 \
                bzImage modules | tee warns.txt
2.3.37 and after: Please set "CONFIG_DYNAMIC_DEBUG=n". That feature uses
declared label things that mess up Smatch's flow analysis.

Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Add test module regression - generic regression test suite

Accept two directories with keyval files (usualy result directories for a test)
and compare given fields according to given pattern.

EXAMPLE: ext4 patch queue validation scenario

 Following example run two static analyzers('smatch' and 'sparse') on vanila
 kernel.
 Step 1: Each analizer produces keyvalue file with number of warnings,errors
 Step 2: Apply patches against vanila kernel and run analizers one more time.
 Step 3: Compare number of warnings and errors collected from vanilla and
         patched kernel and fail if number of errors increased.

I know that we already has some functionality in TKO, but it is too complex
for some usecases. And if we have regression helper which works as simle test
this will perfectly cover patch validation scenario for most develpers.

Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>