Allow for tests to run in parallel (simultaneously from multiple checkouts)

Allow for tests to run in parallel (simultaneously from multiple checkouts)

This is an interim solution and is by no means the final thing. It simply
was possible to do in a short timeframe and cuts the test run time in half.

If you have DSN envvars set, use at least -s -j8 for best results (the
shuffling un-bunches similar tests, see discussion below)

Two things are at play:

First of all every SQLite database and every temp work directory is created
separately using the pid of the *main* test process (there can be children)
for disambiguation. Extra cleanup passes have been added to ensure t/var
remains clean between runs.

All other DSNs are reduced to their ->sqlt_type form and the result is used
for a global lockfile. Said lockfile is kept in /tmp so that multiple
testruns from multiple directories can be run against the same set of
databases with no conflicts.

Some of the tests are explicitly exempt from any locking and will run
regardless of environment, for example t/storage/dbi_env.t

The lockfiles are deliberately placed in File::Spec->tmpdir. This is done
so that multiple dbic checkouts can run against the same set of DSNs without
stepping on each other's toes.

Some notes on why this is not a great idea, even though it works flawlessly
under continuous test cycling: The problem is that our tests are not yet
ordered in a spwecific way. This means that multiple tests competing for
the same resource will inevitably lock all available test threads forming
several bottlenecks along the path of execution. This issue will be adressed
in a later patch, with the following considerations:
  - prove -l t/... must continue to work as is
  - test aggregation is something the test suite should try to avoid in
    general - after all DBIC is intended to be usable in CGI (yes, pure CGI)
    environments, so if the tests are getting heavy to run - this is an
    actual problem in need of fixing. Aggregation will instead sweep it under
    the rug
  - general reorganization of test groups / various path changes should only
    be attempted once we have a solid base for multi-db test runs