Remove environment lock

We protect Qt's accesses to the environment variables (and certain other globals that happen to have moved there afterwards, like tzname[]) with a lock, and require users to use only the Qt functions to access and manipulate the environment.

This is a band-aid that should come off again.

On one hand, it penalizes the vast majority of apps that never modify their environment after start-up, on the other is doesn't actually work when the app links to 3rd-party libraries that don't know about and therefore don't use Qt's lock. In the worst case, another library had the same idea, and we get into a dead-lock situation when these locks are taken in a non-constant order (locks don't compose).

We should, instead, document which Qt APIs access the environment (and other global problematic state) and when, and then remove our lock and leave it to the user to orchestrate or externally synchronize access to these global resources himself. Qt cannot do this effectively, nor any other library, unless the whole development community agrees on a single libenvvar that does it for everyone. Barring that utopia, the application that binds libraries together must take responsibility, and most won't notice a thing, except a significant speed-up (cf. e.g. QTBUG-82268).

Acceptance criteria:

• all global problematic state has been identified:
  • environment
  • tzname[], daylight, timezone etc
  • ...
• there's a central list of all the functions in Qt that read from / write to each of these globals, linked from e.g. the QProcessEnvironment page, or whatever is most apt
• the lock has been removed
  • maybe provide an opt-in before Qt 7 that allows users to run their apps with the in a thread checker before we make the switch
  • maybe provide an opt-in in Qt 7 to keep the Qt 6 behaviour for compat