[FEATURE] Port Perl/CPAN support from conda-skeleton to Grayskull

[mbargull]

Is your feature request related to a problem? Please describe.
grayskull is currently only able to create Python/PyPI-based recipes.
Support for R/CRAN has been looked at already in gh-7, gh-306, gh-349.
Support for Perl/CPAN would be good to have, too, esp. because of the current ongoing efforts by @xileF1337 and @cbrueffer to add Perl packages to conda-forge.

Describe the solution you'd like
Let grayskull handle conda-skeleton cpan's job, too.

Describe alternatives you've considered
It's either Grayskull or yet another project -- I'd like grayskull to have even more power ;).

Additional context
conda-skeleton will likely be deprecated in the foreseeable future.
It would be nice to have Grayskull extended with more use cases by then so we can point users directly to Grayskull in some conda-skeleton deprecation notice, as mentioned by @travishathaway in conda/conda-build#4640.
Also, importantly, grayskull can have faster turnarounds than conda-skeleton (which is bound to conda-build's release cycle) and be more approachable for contributors with Perl/R/etc. packaging expert knowledge due to its tighter scope.

[mbargull]

One question upfront: Are there any intended restrictions on grayskull's dependencies or how it operates?
If one were to port conda_build.skeletons.cpan more or less exactly, we'd need to depend on some Conda package manager (can be any of conda/mamba/micromamba).
The reason for that is that conda-skeleton cpan currently creates a temporary environment with the perl package to query it about which Perl modules are core modules (since we want to avoid creating empty recipes for those).
If that strategy is problematic for Grayskull, adding CPAN-based recipe generation might be more involved since one has to come up with another reliable way to sift out the core modules (read: need expert knowledge or read up on Perl's inner workings).

[xileF1337]

It sounds good to add Perl support to Grayskull as well if it is supposed to replace conda-skeleton. Adding to @mbargull's question concerning constraints on Grayskull's implementation and way of operation, I would like to ask what exactly was the reason for writing a new recipe generator, given there is conda-skeleton? The official website says it makes better recipes faster, but why not simply improve conda-skeleton to do so? When simply incorporating conda_build.skeletons.cpan into Grayskull, what would be the improvement?

The reason for that is that conda-skeleton cpan currently creates a temporary environment with the perl package to query it about which Perl modules are core modules (since we want to avoid creating empty recipes for those).
If that strategy is problematic for Grayskull, adding CPAN-based recipe generation might be more involved since one has to come up with another reliable way to sift out the core modules (read: need expert knowledge or read up on Perl's inner workings).

I would say that the definition of what a core module is not a technical one, it is something that is agreed upon by the Perl distributors. It simply means that a module is important and maintained and should be included in a default Perl distribution (though I have encountered Perl installation on some Linux distros that have core modules in a separate package that was not automatically pulled in by the Perl interpreter). Core modules are often (not always) distributed independently of Perl on CPAN, so they can be updated if the user wishes to do so. While it may be sensible to not add these modules as explicit requirements in recipes to avoid unneccessary downloads, I personally consider the policy of not providing packages for core modules at all to be a bit questionable.

That being said, Perl core module detection is something that I think can only be done by looking up the core module list for the respective Perl version (modules become core in a certain version and may also be removed from core in a later release!). They are provided in Perl itself via the (core) module Module::CoreList, e.g. with the following code taken from conda skeleton:

use Module::CoreList; 
print join "\n", grep {Module::CoreList::is_core($_)} Module::CoreList->find_modules(qr/.*/);'

Such a list could be compiled once for every Grayskull release and then used to look up each module. The core list is also available on the web (e.g. via https://perldoc.perl.org/5.32.1/modules for Perl v5.32.1) and could be fetched from there, too, without using Perl. Doing this at runtime would also allow Grayskull to support Perl versions released after that respective Grayskull release.