getenv: Make os.getenv() show a better error

[jepler]

.. when an associated value is not a quoted string. This includes some cases where it would previously return an integer, a CPython incompatibility.

However, it's an incompatible behavior change with circuitpython since previously a number would be returned.

Closes: #9113

[Neradoc]

If we are completely disallowing ints then it's a breaking change that we need to document clearly with the mention that we only accept strings in our subset of toml (and that they need double quotes).
https://docs.circuitpython.org/en/latest/docs/environment.html#details-of-the-toml-language-subset

• The supported data types are string and integer
...
• Only integers supported by strtol. (no 0o, no 0b, no underscores 1_000, 011 is 9, not 11)

Alternatively we could still allow reading ints but return them as strings (and have a better error) but that could be confusing.

Also, it looks like this preserves common_hal_os_getenv_int, but does that mean that the user code can't read some of the environment variables used by Circuitpython ?

CIRCUITPY_WEB_API_PORT=8000
CIRCUITPY_DISPLAY_WIDTH=640
CIRCUITPY_DISPLAY_COLOR_DEPTH=1

[jepler]

I have no HW so I'm not able to test on HW, but under this PR the intent is that internal routines that get integers will continue to work as before.

It is only intended to change the os.getenv API so that it can no longer return integers (cpython compatibility) and will issue a better error message in the case that a non-quoted value is encountered with a key passed to os.getenv.

I'm not sure whether I'm in favor of this change myself, because as you say it ought to go through deprecation and does remove the ability to read integer-syntax values from settings.toml into python code without adding it back in some hidden way. It's just that I was still being copied on comments on #9113 and noticed a recent one go by. I decided to check into the coding required to implement CPython compatibility and this is what I came up with. But I'm not actually itching to see it merged, to be honest.

[dhalbert]

I'm making this draft so it won't get merged by accident. I'll discuss this further in #9113.

[jepler]

Closing as this is not likely to be merged as-is.