Engage nuclear option of travis testing

Engage nuclear option of travis testing

For the record - I am not happy about having to make this commit. However the
reality is that for every basic toolchain module I fix, another two are broken
by dzil-addicted (though well meaning) folks. Since this essentially paralyzes
any useful work, resort to simply ignoring some of the meaningless tests that
are autopopulated by ill-designed dzil author bundles.

This allows to revert 655d80dd, 72cd4007, and generally streamline the set of
workarounds

A preemptive note for anyone who is concerned that I am wasting precious tuits
on a dubious goal. Please realize that one of the corner stones of my personal
desire to participate in OSS comes from disdain of forced obsolescence (i.e.
one shall upgrade each and every year because the author feels like it). If I
can not guarantee my software performs correctly on old but usable versions of
our beloved VM - a massive portion of the very reason I "keep playing" goes
away entirely. With that gone the world beyond OSS suddenly becomes
exceedingly more appealing, at least much more appealing as opposed to pushing
features into a library unusable by most real-world production environments.
Additionally whether I or anyone else has encountered users benefitting from
my efforts is not relevant - the DarkPan universe is vast.

In other words instead of seeing these activities as a mindless fetish,  see
them for what they are: one of the main reasons I am a CPAN contributor to
begin with.

--ribasushi