Convert frozendict/src/*/cpython_src/ to use submodules instead of manually-copied files

[lurch]

This is obviously a "cleaner" way of doing things (it means less files stored directly in the repo), and it means that if the upstream Python-headers change, you only need to update the relevant commit-hash in .gitmodules and then git submodule update.

The downside is that this then leads to 5 separate copies of the complete upstream https://github.com/python/cpython repo being stored in your local workspace, gobbling up over 2GB of diskspace 😢 Unfortunately the --depth option of git sumbodule add doesn't work in combination with the -b option https://git-scm.com/docs/git-submodule
(I also tried having just one submodule pointing to the main branch of upstream cpython, and then having each of the 3_6, 3_7, 3_8, 3_9 and 3_10 submodules pointing to this "shared" submodule, but git doesn't allow you to do that).

So it's entirely up to you @Marco-Sulla whether you want to accept this or not.
(Just in case you've not used git submodules before - after cloning this PR you need to run git submodule update --init ... and then wait a while... 😉 )

[Marco-Sulla]

The downside is that this then leads to 5 separate copies of the complete upstream https://github.com/python/cpython repo being stored in your local workspace, gobbling up over 2GB of diskspace

Ok, I think this is enough to reject the pull X-D. Thank you anyway for the idea :)

[lurch]

Haha, no problem 😄
I guess an alternative approach could be to have different 3.6, 3.7, 3.8, 3.9 and 3.10 branches in python-frozendict as that way you'd only need a single cpython submodule (with each branch of python-frozendict setting the submodule to a different commit), but I've no idea if that would "work" as I've never written a C-based Python module.