Generate pyver etc. when depending on Python-core

[Micket]

As I've started to use Python-core at GCCcore level, I found that when moving some depedencies, like wheel-0.31.1 to GCCcore 7.3.0, it failed as %(pyver) initialized by the template code.

This simply introduces name Python-core as an alternative as a fix.

[boegel]

@Micket I wonder if there's a better way of handling this... The amount of elements in that list is fairly limited now, but it could grow over time, so it's important to keep this organized.

At the very least, it should be grouped like (('Python', 'Python-core'), 'py'), but that implies that the places where TEMPLATE_SOFTWARE_VERSIONS is used now need to be tweaked too.

I also wonder how flexible this should be w.r.t. name (what if people go with PythonCore, similar to GCCcore, etc.).
We currently don't have Python-core in the central easyconfigs repo yet (but we probably will fairly soon, see the discussion in easybuilders/easybuild-easyconfigs#5072. Are you basically using Python-core as it was proposed there?

[Micket]

@boegel It's not quite the same as easybuilders/easybuild-easyconfigs#5072, because (as it's title suggest) would be limited as a only a build-dep, which, in my opinion, renders it completely pointless.
I do exactly this: easybuilders/easybuild-easyconfigs#6537
(and the corresponding split for 3.7.0/3.6.6).
I.e. my Python-2.7.. has a runtime dep on Python-core-2.7, so the intel compiled numpy runs on top of a gcc(core) compiled libpython.

(As long as we move the interpreter and libpython to GCCcore, to be used as runtime depedencies, I'm perfectly happy with any solution, but, from the experience so far, there may be a big cost due to keeping the basic name "Python" to refer to the numpy bundle, such as issues like this)

[akesandgren]

@Micket is this still valid?

[Micket]

No