add supervisor.get_setting(); change os.getenv() behavior

[dhalbert]

• Fixes os.getenv("A_NUMBER") can return an int #9113

See #9113 for the motivation for this PR. There are also various issues where people would like a way to turn on/off something completely, like a workflow or some startup behavior: the new boolean support will make that easier.

• os.getenv(key, default=None) now always returns a string. It never raises an error. It will return whatever is on the right hand side of key = <value> in settings.toml after removing leading and trailing whitepsace. The value is returnedeven if that value is not valid TOML, such as an unquoted string. If the key cannot be found or there is a pathological problem (bad Unicode escape, etc.), it will return the default value.
• A new function supervisor.get_setting(key, default=None) is added. It parses key = <value>. The value must be one these kinds of valid TOML values:
  • a double-quoted string, and is returned as a str.
  • an integer, signed or unsigned. The value is returned as an int.
  • true or false, returned as the Python boolean True or False.
  • Any other kind of value raises ValueError. If key is not present, then the value of default is returned.

Internally, these changes were made:

• The code in shared-module/os/getenv.c was moved to supervisor/shared/settings.c, and was slightly simplified. The routines were renamed from common_hal_os_getenv_* to settings_*. The error reporting is simpler and doesn't bother to report the particular offending bad character. Errors that occur when trying to read, say, CIRCUITPY_WIFI_SSID are still printed in the REPL stream for the user's benefit.
• CIRCUITPY_OS_GETENV is now CIRCUITPY_SETTINGS_TOML.
• The tricky code that tests os.getenv() in the unix micropython variant=COVERAGE build is now simpler and smaller. The test was updated to handle the new behavior of os.getenv().

The original code is now slightly smaller, but adding supervisor.get_setting() added about 260 bytes.

The original version of this code was developed using Copilot CLI using the GPT-5.3-Codex model and some fairly specific prompts about what I wanted. The code worked, but I then had further ideas about how to structure the code and do some cleanup, and did most of that by hand. I also reworked the documentation Codex wrote. Some refactoring and renaming was left to Copilot. I reviewed all the new diffs and new code.

Tested on Metro M4 and Metro ESP32-S3. Automatic WiFi access point connection worked as expected with settings.toml values as before. supervisor.get_setting() was tested manually.

Aside: I'd like to have written automated tests for supervisor.get_setting(), but that's not possible with the current UNIX micropython executable. The POSIX port (#9581) would be a move in that direction, as would, say an ARM executable on qemue or something like rp2040js/wokwi.

[tannewt]

Why not add a tomllib module instead of adding a new supervisor API?

[dhalbert]

Why not add a tomllib module instead of adding a new supervisor API?

tomllib has a simple API but loads the entire TOML file as a dictionary, which doesn't match well with the internal API we already need to look up single values when the VM is not running and we can't allocate a dictionary and its objects easily. tomllib doesn't have a single-value lookup API. But we can brainstorm on this.

[tannewt]

We chatted about this and decided this is ok. We want internal typed supervisor APIs and it makes sense to give the user access through the supervisor module.

[Montiwa11]

@weblate