Cache env config

[bennyrowland]

This commit adds a new cache to the main config object, specifically for env config. When env config is retrieved via Config.get_env(), it is not in general possible to determine whether the env is a packaging environment or not. Because retrieving standard section config needs to know which "base" section to inherit from, and this is different for test envs and packaging envs, we require a separate way to retrieve previously created env config. At creation time we do reliably know whether this is a packaging or run env, and we want that to persist (if it changes, we call clear_env() and recreate it with the new type).

At the moment, there are no tests for this change, I would appreciate a) approval of this approach to fixing the problem and b) some guidance about where to put a test (or possibly just add some additional checks to an existing test, to demonstrate e.g. that {envtmpdir} is being expanded). I have verified that my project that got me interested in this issue now builds correctly with this fix.

I don't think any change to the documentation is required for this. I will add a changelog entry along with the tests.

Fixes #3238.

• ran the linter to address style issues (tox -e fix)
• wrote descriptive pull request text
• ensured there are test(s) validating the fix
• added news fragment in docs/changelog folder
• updated/extended the documentation

[gaborbernat]

Looks alright, you'd want to create your example in a config and check that tox -c expands correctly.

[bennyrowland]

Ok, interestingly, tox config does deliver the correct expansion of placeholders - I think because it is not getting as far as running the commands it doesn't re-request the env and so doesn't get the second, incomplete, version.

This means that we will have to make a proper run to test this (AFAICT). I am continuing to work on this (in limited spare time) but it has become more complicated than it first appeared (why are the tests always harder than the fix itself), and may take a bit longer to get to a solution.

[gaborbernat]

why are the tests always harder than the fix itself

That's expected 😊 writing code is fairly easy compared to maintaining it.