benchmark-unify: a Perl script to convert benchmark output for relbench
Several enhancements for relbench

1.
If there are benchmarks that exist only in file 1 and benchmarks
that exist only in file 2, point out the possibility to convert
both benchmark files using benchmark-unify, so that more
benchmarks might be compared

2.
If a particular benchmark appears several times in the same file,
print a message to STDERR, and pick the higher values for
comparision (higher real value is considered here, only if the
real values are the same, the higher virtual value is considered).

3.
Add support for an optional verbose mode:

./relbench -v file1 file2
instead of
./relbench file1 file2

With verbose mode, for each benchmark that exists in both files,
the ratio of real / virtual c/s rate is printed like this:

Ratio:	0.95543 real, 0.96987 virtual	generic crypt(3) DES:Only one salt
Ratio:	1.00379 real, 1.00388 virtual	HalfLM C/R DES:Many salts
Ratio:	1.06590 real, 1.06586 virtual	FreeBSD MD5:Raw
Ratio:	2.92454 real, 1.47022 virtual	Invision Power Board 2.x salted MD5:Only one salt
Ratio:	0.97287 real, 0.97287 virtual	dynamic_20: Cisco PIX (MD5 salted):Many salts

This allows to use

./relbench -v file1 file2 |grep "^Ratio:"|cut -f 2-|sort -nr

This way, the benchmarks with the best performance improvement and the benchmarks
with the worst performance regression can easily be identified.
--list=format-details: add number of test cases to output

Furthermore, clanup unnecessary code for --list=format-details
(which had been copied from the --list=formats code)

Added --list=formats and --list=format-details description to
doc/OPTIONS
Fix gcc warnings in --list=format-details code
Portability_issues_unstable.diff
Unify name of "local work size"
relbench: important fix for duplicate format names in file1

Without this fix, for the first file the last benchmark of each format
would be counted (as was the case prior to my changes), whereas for the
second file the fastest one would be counted (which was the intended
logic for both files.

Now, it is always the fastest one that counts.
relbench: update copyright, and change revision from 4 to 4.1
john-mpi.c: Do not include omp.h unless OMP build
CUDA fixes
GOST rename from "GOST 3411" to "GOST R 34.11-94"
Remove two unused variables from opencl_bf_std.c
Add a second test vector to PHPS_fmt_plug.c
Some documentation fixes for dynamic formats
Fix a (clang) compiler warning in MYSQL_fast_fmt_plug.c
benchmark-unify: map "MYSQL" to "MySQL" and "NT v2" to "NT MD4"

Otherwise, only the fastest of both benchmarks of newer jumbo revisions
will be compared with the MYSQL_fast implementation, even if for some
reason the MYSQL_fast implementation is slower than the MYSQL one.
Comparing the fastest of two MySQL implementations of an older jumbo
version with the fastest of two MySQL implementations of a new jumbo
version (> john-1.7.9-jumbo-5) is only fair.
And it also gets rid of the "Only in file 1: MYSQL:Raw" output when
running relbench.

The same logic applies to the mapping of NT v2 to MT MD4.
Move MYSQL_fmt_plug.c to unused/, rename MYSQL_fast_fmt_plug.c to mysql_fmt_plug.c
and change its label to just mysql
Use a different format name for raw-sha1-ng, due to max. pwlen 15
CHANGES-jumbo updates. Hard to keep terse, we could drop more
CHANGES-jumbo don't repeat last names