Remove support for end-of-life Pythons

[jdufresne]

Match pip support Pythons and remove support for end-of-life Pythons.
pip has not support Python 2 since 21.0 (2021-01-23). For dates on when
these environments went EOL, see:

https://devguide.python.org/devcycle/#end-of-life-branches

Removing support for Python2 allows for several simplifications:

• Remove use of toml package in favor of tomli
• Remove compat.py
• Replace io.open with builtin open
• Replace tempdir function with tempfile.TemporaryDirectory
• Replace mkdir_p function with os.makedirs
• Remove use of mock package in favor of unittest.mock
• Remove import from future module
• Remove unnecessary inheritance from object

Refs #90

[hugovk]

Here's the pip installs for pep517 from PyPI for October 2021 showing low numbers for EOL versions (<3.6):

category	percent	downloads
3.8	67.63%	4,113,564
3.9	16.02%	974,421
3.7	9.80%	596,365
3.6	4.26%	259,225
3.10	1.58%	96,366
null	0.42%	25,371
2.7	0.22%	13,406
3.5	0.05%	3,287
3.11	0.01%	402
3.4	0.00%	24
3.3	0.00%	5
Total		6,082,436

Date range: 2021-10-01 - 2021-10-31

Source: pip install -U pypistats && pypistats python_minor pep517 --last-month

[takluyver]

Suggested change

	"Programming Language :: Python :: 3.6",
	"Programming Language :: Python :: 3.7",
	"Programming Language :: Python :: 3.8",
	"Programming Language :: Python :: 3.9",

I deliberately leave these classifiers out. The requires-python field specifies the same thing in a more precise and useful way (useful because pip respects it), and doesn't have to be updated when a new Python version comes out.

[jdufresne]

No problem. I will remove it.

FWIW, some users use this information to determine the suitability of library within a particular project. It helps communicate precise minor versions support and how up to date a release is. Further, the trove classifiers are easier to parse so it is useful for scripts.

[takluyver]

Thanks, and sorry it's taken me a while to get round to looking at this. It basically looks good, and the statistics @hugovk shows make a good case for it.

@FFY00: do you still want a release which falls back to loading toml even on newer versions of Python, as in #125? This PR removes the use of toml altogether, so if you still need that, we can hold off merging this for a little bit longer.

[FFY00]

I don't think we need it. In build, it turns out, we don't actually use anything that requires loading TOML, so it is possible to bootstrap without it anyway.

[takluyver]

Great, in that case I'll close #125 and go ahead with this simplification. 🙂

[jdufresne]

Thanks for the review @takluyver ! I have addressed all feedback in the latest revision.

[takluyver]

Thanks @jdufresne !