Use a virtual environment for Python packages by default

[multiplemonomials]

Summary of changes

Using Mbed lately, and watching others use it, I have been feeling like the need to install Python packages, and to reinstall them if Mbed adds a new requirement, causes annoyance for people a lot of the time. Traditionally I've been a bit of a critic of venvs but as I have gotten more into Python development I have understood their value more. It's simply too common to have broken system packages, or a system with a too old version of a package, or a dependency conflict with something else you have installed.

While it's still nice to have the option to use system packages if needed, making the default to create a new venv with all the correct stuff seems like it will make Mbed more user friendly, and therefore, is worth doing. The venv uses about 60MB per instance on my machine, which is not nothing, but still pretty manageable, especially compared to the size of Mbed itself.

Impact of changes

By default, Mbed's CMake scripts will now create a virtual environment under the mbed-os source dir when run for the first time. The venv is located in the source dir to de-duplicate it, as it is not specific to a given build directory.

The option -DMBED_CREATE_PYTHON_VENV=FALSE can be passed to CMake in order to disable this and switch to the old behavior of using the system interpreter.

Also, I fixed two other annoying issues in this PR:

• Up until now, modifying mbed_app.json or custom_targets.json and then running ninja did not cause the configuration to be regenerated because CMake was not rerun. This has been fixed; CMake will now be rerun.
• Setting a nonexistant property in your target_overrides section did not cause any error or warning to be printed. Now, a visible warning will be printed to the console. (turned out we were missing the -v option to mbed-tools)

Migration actions required

Documentation

Once this PR is approved I will update all of the wiki pages to remove instructions to install the Python packages. It should be a bit simpler!

---

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] 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

---

Reviewers

---

[JojoS62]

great feature, tested in Linux machine and it works.