This commit introduces a new function `run_tests` to the Odoo shell.
This function allows users to run specific tests directly from the
shell, even after the test code is modified. This significantly speeds
up the debugging process by avoiding the need for a full server restart.

In the odoo shell
```
>>> from odoo.tests.shell import *
>>> run_tests(env, 'test_tags', modules=[module_name], reload_tests=True)
```

Note: `run_tests` automatically reloads test modules but does not reload
Odoo model code. A shell restart is still required after any change to
business logic.



used by
https://github.com/HydrionBurst/odoo-test-vscode
for hot test
vscode extension: 
[odoo-test-0.0.1.vsix.zip](https://github.com/user-attachments/files/22089685/odoo-test-0.0.1.vsix.zip)


tutorial: https://github.com/HydrionBurst/odoo-test-vscode?tab=readme-ov-file#-hot-test



Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#225024
Forward-Port-Of: odoo/odoo#224048

Description
-----------
When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening:

1) Once in `convert_to_column`, when converting the `vals` for
   *database* insertion
2) Once post-insert in `convert_to_cache`, when converting the
   `vals` for insertion in the *cache* for the newly created records.

This redundancy has a negative performance impact when creating many records where new HTML fields are set, e.g., mass-mailing, as potentially large HTML documents are parsed and validated, often with external libraries.

To address this issue, this commit removes the insertion into *cache* of the HTML values for the newly created records. This removes the overhead of the second sanitization, speeding up the creation, and also helps with overall memory pressure, as we're not inserting large HTML fields into cache. The latter is particularly noticeable for long-running batch creation processes that do *not* commit intermediate results.

The downside of this patch is the potential *cache-miss* (and therefore the subsequent *query*) if the HTML field of the newly created records is read. This is unlikely in business code because intrinsically, an HTML field is often just a data 'blob' that has no logical usage. In the rare case where it needs to be read after creation, since the value in the database is already sanitized, re-sanitization is not necessary for insertion in the cache. Given these considerations, the trade-off seems reasonable to make.

Benchmark
---------
In a scenario for a marketing campaign with 1000 recipients, using a *mid-sized* email template and emulating a typical campaign, the results were:

| Method                        | Before   | After     | Speed up |
|-------------------------------|----------|-----------|----------|
| `_process_mass_mailing_queue` | 2.84 min | 1.55 min  | 1.8x     |
| `create`                      | 2.11 min | 50.23 sec | 2.5x     |

This represents roughly a *2x* performance improvement in processing an email campaign.

* more detailed benchmarks are available in the task's description

Reference
---------
task-4962646

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#224534
Forward-Port-Of: odoo/odoo#223875