It appears that travis drastically increased the amount of available CPUs

Well, this is awesome - we just happen to be equipped to take advantage
of this ;)

Remove the branch-name limitations - now a smoke takes fraction of the time
it used to, no point to limit what we smoke anymore.

At the same time reduce the amount of threads building the perls - older
binaries do not build very well on -j32. This is a temporary thing - the
perl-building will soon be exported away anyway.
Readjust the parallel no-test dependency install order

Better utilize the massive amount of CPUs we have available
New Test::Strict no longer detects Moose::Role (RT#83433) - workaround
Modify the null-branch pruning introduced in ce556881, restore compat

In the case of "direct to HRI" we want to throw stuff away as before. In
other cases however we no longer take an educated guess when to prune.
Instead we mark each null-branch by simply blessing its containing
arrayref. This allows us to keep the arguments to inflate_result 100%
backwards compatible, while at the same time allowing "enlightened"
inflate_result implementations to skip over the dead branches with
minimal effort.

Both ::Row::inflate_result and ::HRI::inflate_result were adjusted to
react correctly to these marks. As a result the HRI folder gained
another 5% speedup (unless sidestepped by the direct-to-HRI code, which
is naturally much much more efficient).

The current name of the "null class" is stored in the global
$DBIx::Class::ResultSource::RowParser::Util::null_branch_class. Given
that the entire codebase begs for standalone CPAN extraction this should
do for the time being.

While implementing the test changes it became clear that
Test::More::is_deeply does not cut it (it ignores the blessed-ness of
structures by design: https://github.com/schwern/test-more/issues/347).
As a result a dep on Test::Deep was added, and several of the tests
looking at inflate_result RVs were converted.
Fatalize warnings within the compiled row parsers

Encountering an undef value anywhere in this code is a sign of some glaring
omission. Perhaps a nullable column is annotated as is_nullable => 0 or
something similar. When this is the case we need the collapsing to stop
right there, as it is no longer safe to proceed.
Optimize the HRI-direct collapser even more

Since we know that we will never output null-branches in the case of
HRI, we can wrap the related assemblers in a definedness condition to
never fire on a null branch, and skip entirely the calculation of
non-NULL %cur_row_ids.