pythonversion breaks "_info" pattern of other grains.

Description of Issue

pythonversion grain breaks model of fooversion/release and fooinfo

What I mean by that is that pythonversion is not a simple string or int, but instead a list.

pythonversion:
    - 2
    - 7
    - 5
    - final
    - 0

It should instead be like 'osrelease: 7.9.2009' with the list varient named pythonversion_info.

I'm well aware this is a problematic and backwards incompatible change.

May I suggest adding "pythonrelease: 2.7.5" and "pythonrelease_info: [2, 7, 5, final, 0]" grains?
Then at some well documented future date having pythonversion go away.

Setup

Any salt version, at least through 3002.2

Steps to Reproduce Issue

salt-call grains.item pythonversion
local:
----------
pythonversion:
- 2
- 7
- 5
- final
- 0

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
salt --versions-report
Salt Version:
Salt: 3002.2

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
docker-py: Not Installed
gitdb: 0.6.4
gitpython: 1.0.1
Jinja2: 2.11.1
libgit2: Not Installed
M2Crypto: 0.35.2
Mako: Not Installed
msgpack: 0.6.2
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 3.6.8 (default, Nov 16 2020, 16:55:22)
python-gnupg: Not Installed
PyYAML: 3.13
PyZMQ: 17.0.0
smmap: 0.9.0
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.1.4

System Versions:
dist: centos 7 Core
locale: UTF-8
machine: x86_64
release: 3.10.0-1160.15.2.el7.x86_64
system: Linux
version: CentOS Linux 7 Core

Start by reproducing the reported output with salt-call grains.item pythonversion, then inspect the grain implementation and related fooversion and fooinfo grains. Done means the Python version grains follow the agreed naming and value structure while documenting and handling the stated backward-compatibility impact.