A cpanfile with detailed prerequisites

This helps clarify the dependency chain and opens up structured optional
features for users.
Switch to Dist::Milla for the release management process

Dist::Milla is a simply a nice out-of-the-box configuration of
Dist::Zilla.  Several regular Dist::Zilla plugins are used as well.

A Makefile.PL is kept checked in so that only authors making releases
need to use Dist::Milla.  Everyone else just installs and uses the
repository as usual.  The Makefile.PL (and other generated files) may be
updated at any time by running:

    milla build --no-tgz && milla clean
Add author prereqs for the develop phase
Restore support for section 1 and section 3 man pages

Note that this preserves the bug of two hash keys for README.pod,
leaving only recs(3) installed and not RecordStream(3).  Since all the
documentation refers to RecordStream(3), I will be fixing this in the
future during a documentation update.

I fully intend for this to get less ugly in the near future by changing
how the docs are built (and slimming down the dist.ini again).
Restore doc generation at user-install time

Some of the operation docs incorporate system-specific values (such as
fromps) into their documentation.  This simply restores the previous
behavior before the Dist::Zilla conversion.
Remove reliance on BuildTools.recsbuildtool for generate_pods.pl
Make XS dependencies optional but strongly recommended

Don't require XS versions of JSON and Text::CSV.  The pure-Perl versions
are slower, but work.  Where the XS versions are available, they'll be
automatically used.

Switches to JSON::MaybeXS while we're at it, since it has a) better
dependency handling/detection and b) prefers Cpanel::JSON::XS over
JSON::XS.  The former is more reliable, community-driven, and more
developer-friendly than the latter.  JSON::MaybeXS will use JSON::XS if
it's the only XS option available.  Failing any XS available, it falls
back to JSON::PP of course.

Term::ReadKey is nice, if we have it, but otherwise relying on $COLUMNS
from the environment and defaulting to 80 is very reasonable.

Making these three XS deps optional means it's possible to fatpack recs.
Use Module::Pluggable to find and require aggregators/clumpers/deaggregators

It's better than the previous ad-hoc method in several ways (e.g. more
resilient to unexpected files), but most importantly version 5.1 and
newer know how to play nicely with App::FatPacker's @INC entry.  This
ensures that core packages are located even when fatpacked.

Module::Pluggable itself comes with no non-core deps, which is great.
(Though it used to be core itself, it no longer is and, besides, the
version we need was never in core.)
Add a "recs" executable which dispatches to individual operations a la git

This allows for git-style invocation of subcommands such as:

    recs fromcsv --header ...

More importantly, having a single command provides an obvious
point-of-entry for fatpacking the builtin operations into a single
bundle.

Similar to git, all that's necessary to add a subcommand is having an
executable in the PATH beginning with "recs-".  Operations are
preferentially loaded from the Perl lib paths, which includes the
builtins provided by the core distribution.  This saves a re-exec of
perl when it isn't necessary and will also run core operations when the
whole dist is fatpacked into this script (and hence there aren't
seperate recs-* scripts).
Infrastructure for fatpacking bin/recs into a standalone script
Check in fatlib/ and the fatpacked recs script

We want to keep track of changes to both of them.  The local/ directory
contains arch-specific packlists and paths which must match the current
machine when fatpack runs.  For this reason, we don't keep local/
checked in.

Note that local/, fatlib/, and the fatpacked recs script are all
excluded from the CPAN dists so that they don't increase the dist size
and aren't indexed by PAUSE by mistake.
Add a --version option to recs
Use perlstrip to reduce the size of the fatpacked recs by 33%

Down from 11MB to 7.4MB.
perlstrip'd recs
Specify JSON::PP explicitly when fatpacking

Otherwise it won't be fatpacked when building on Perl 5.14 or higher,
which includes JSON::PP in core.  To support older Perl's, we explicitly
specify it.
Report un-copied but traced modules

This can help local debugging if something unexpected pops up.

For example, it revealed that Date::Manip uses %+ which is a Perl 5.10
feature (via Tie::Hash::NamedCaptures).  Luckily for us, the DM5 backend
doesn't require 5.10.

Modules which are known OK to skip are marked as such.