Perl layout for 5.26+

[Yaakov Selkowitz <yselkowitz@cygwin.com>]

With the upgrade to 5.26, we will need to rebuild every single Perl 
module package again.  While we have no choice for 5.26, I would like to 
implement a method of minimizing the effort that will be needed in 
future upgrades.

For 5.22 we had:

prefix=/usr
privlib=/usr/lib/perl5/$slot
archlib=/usr/lib/perl5/5.22/$archname
vendorlib=/usr/lib/perl5/vendor_perl/5.22
vendorarch=/usr/lib/perl5/vendor_perl/5.22/$archname
sitelib=/usr/lib/perl5/site_perl/5.22
sitearch=/usr/lib/perl5/site_perl/5.22/$archname

Instead, we should switch to:

prefix=/usr
privlib=/usr/share/perl5/5.26
archlib=/usr/lib/perl5/5.26
vendorprefix=/usr
vendorlib=/usr/share/perl5/vendor_perl
vendorarch=/usr/lib/perl5/vendor_perl/5.26
siteprefix=/usr/local
sitelib=/usr/local/share/perl5
sitearch=/usr/local/lib/perl5/5.26

By un-versioning privlib/vendorlib/sitelib, it will no longer be 
necessary to rebuild noarch Perl module packages -- which are the large 
majority (~70%) -- with every single 5.Y release of Perl.  In other 
words, if we do this for 5.26, then for 5.28+ only ~110 packages will 
need to be rebuilt instead of ~350 (besides those which link against 
libperl but do not install anything into any of those locations).

Using lib for archful things vs. share for noarch, and /usr/local for 
site*, is for compliance with FHS, and the latter avoids a lot of 
confusion over which should be used by packages.

I implemented a similar scheme for Ruby, which makes it *much* easier to 
upgrade to new versions thereof.  Fedora does something similar, so 
there is plenty of precedent for such a move.

-- 
Yaakov