Create a proper Python project for the Python scripts

[multiplemonomials]

Summary of changes

This PR creates a proper Python project (with a pyproject.toml) for all of the Python scripts used by Mbed. Previously, these just lived in a folder with a requirements.txt. Not only was this janky, but it also meant that executing the scripts was a huge pain, because you had to do

$ cd mbed-os/tools/python
$ python -m mbed_tools.cli.main <command>

in order to execute things.

With this PR, we now have a proper Python project, so it can be installed into the virtualenv and then you can just do

$ mbed-tools <command>

I ended up using Hatchling for this, rather than something more complex like Poetry or uv, as there are no native modules or other complex things in the packages, and it seemed like the simplest thing that would work.

The other big change I made is that now the pyocd and cysecuretools packages are installed lazily, instead of being included in the default set of dependencies. Both of these packages had pretty chonky sets of dependencies, and both were not needed for basic use cases of Mbed CE. Removing them should make stuff like CI builds run a bit faster and use less dependencies.

Pyocd is now installed the first time the PYOCD upload method is used, and cysecuretools is installed only when the Cypress TFM post-build script is used (i.e. for the CYTFM_064B0S2_4343W target only).

Impact of changes

• Tools like memap and mbed-tools can now be run as commands (after activating the venv) rather than having to cd into the tools/python folder
• Improvements to venv creation to be a bit more robust
• Improved check of the python interpreter when Mbed venv is disabled, it now verifies that the mbed ce tools package is actually installed into the interpreter instead of just checking a few dependencies
• pyocd and cysecuretools (and all their many dependencies) are now installed lazily when needed

Migration actions required

If you are using the default venv mode, no migration actions are needed. If you disabled venv mode via MBED_CREATE_PYTHON_VENV=FALSE, then the following command:

python -m pip install mbed-os/tools/requirements.txt

has changed to:

python -m pip install -e mbed-os/tools

Additionally, if not using the venv, you will need to install pyocd and/or cysecuretools manually if you were depending on these packages, as they are no longer included in the base Mbed requirements.

Documentation

Once this is merged I will update wiki pages to use the new shortened commands for things

---

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[X] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

[multiplemonomials]

I have noticed two scenarios here that seemed to cause problems over the last year or so:

1. The python venv is corrupted in some way (e.g. by removal of the system Python that it is pointing to). This causes find_package(Python3) to fail, with an error like "Python interpreter could not be run"
2. The python venv is deleted, which will cause find_package(Python3) to silently return the system python instead of the venv.

I attempt to handle both those cases here. I have confirmed that #2 is fixed now, but I have not found a reliable way to reproduce situation #1 yet, so I sort of threw everything at it in the hope that we can make FindPython temporarily revert back to the system python.

[VictorWTang]

Couple really minor comments, but the Python reorganization looks good to me!