Add support for test.valgrind parallel testing

# New Ticket Created by  Matthew Horsfall
# Please include the string:  [perl #121431]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=121431 >

This is a bug report for perl from wolfsage@gmail.com,
generated with the help of perlbug 1.39 running under perl 5.14.2.

-----------------------------------------------------------------
[Please describe your issue here]

The included patch allows test.valgrind to run tests in parallel.

Valgrind output for each test will be printed out after the test
completes, with the name of the test prefixing every line.

Example usage might be:

  TEST_JOBS=8 make test.valgrind VALGRIND='valgrind -q' 2>&1 | tee out.txt

-q is needed to ensure only *errors* are captured, otherwise the output will
be much louder than it already is. (Perhaps this should be the default mode?)

[Please do not change anything below this line]
-----------------------------------------------------------------
mktables: Fix overlooked in-line table defns code

Commit eb0925341cc65ce6ce57503ec0ab97cdad39dc98 introduced the idea of a
pseudo-directory as a way to store table definitions in-line in
Heavy.pl, but conform to the expectations of the code in regard to
objects being files within directories.  This kept the needed changes to
a minimum.  The code changed by the current commit  was overlooked then
as something that also needed to change, because there are no current
instances of it needing to.  But this could change with future Unicode
versions, or as in the next few commits, in extending the in-line
definitions.
utf8_heavy.pl: Change data structure for in-lined definitions

This commit puts the in-lined definitions introduced by
eb0925341cc65ce6ce57503ec0ab97cdad39dc98 into a separate array,
where each element is a unique definition.  This can result in slightly
smaller current memory usage in utf8_heavy.pl, as the strings giving the
file names now only appear once, and what replaces them in the hash
values are strings of digits indices, which are shorter.

But doing this allows us in a later commit to increase the number of
ranges in the tables that get in-lined, without increasing memory usage.

This commit also changes the code that generates the definitions to be
more general, so that it becomes trivial to change things to generate
in-line definitions for tables with more than one range.
mktables: White-space only

This indents code to conform to the new block created in the previous
commit
mktables: Add comments, reorder a gen'd file

This adds some clarifying comments, and reorders Heavy.pl so the array
referred to by two hashes occurs before both hashes in the output.
mktables: Remove obsolete sort constraint

Zero-length tables are no longer expressed in terms of the Perl 'All'
property, so the sort no longer has to make sure the latter is processed
before the former.
mktables: In-line defns for tables up to 3 ranges

eb0925341cc65ce6ce57503ec0ab97cdad39dc98 caused the definitions for
about 45% of the Unicode tables to be placed in-line in Heavy.pl instead
of them having to be read-in from disk.  This new commit extends that so
that about 55% are in-lined, by in-lining tables which consist of up to
3 ranges.

This is a no-brainer to do, as the memory usage does not increase by
doing it, and disk accesses go down.  I used the delta in the disk size
of Heavy.pl as a proxy for the delta in the memory size that it uses,
as what this commit does is to change various scalar strings in it.
Doing this measurement indicates that this commit results in a slightly
smaller Heavy.pl than what was there before eb092534.  The amounts will
vary between Unicode releases.  I also checked for Unicode beta 7.0, and
the sizes are again comparable, with a slightly larger Heavy.pl for the
3-range version there.

For 4-, 5-, ... range tables, doing this results in slowly increasing
Heavy.pl size (and hence more and more memory use), and that is
something we may wish to look at in the future, trading memory for fewer
files and less disk start-up cost.  But for the imminent v5.20, doing it
for 3-range tables doesn't cost us anything, and gains us fewer disk
files and accesses.
Porting/todo.pod: Use F<> instead of C<>

A file path is supposed to be enclosed in F<>