When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to `_is_combination_possible_by_config`. More specifically, calling `attribute_lines.product_template_value_ids` and
`self._get_own_attribute_exclusions` for each combination is pretty slow.

To speed that up, this commit introduces a new method, `_filter_combinations_impossible_by_config`. This method accepts a sequence of combinations and yield those that are valid w.r.t. the exclusions. Because values that only depends on self are computed once before looping through the combinations, this lead to a significant speedup. This method is a generator to avoid MemoryErrors, be able to raise a UserError after "creating" 1000 variants and be consistent with choices made in `_create_variant_ids`. https://github.com/odoo/odoo/blob/0042b9d3eece219d4e89fe9c6ecb9971a1f3bf12/addons/product/models/product_template.py#L710

#### speedup

Customer saas-16.4 database with 378 templates, 3832 products, 44 product.attributes, 186 product.attribute.values, 79 product.template.attribute.lines, 484 product.template.attribute.values, 374 product.template.attribute.exclusions. No dynamic attributes.

Timing to write on product.template, adding a new attribute value on a ProductTemplate Form increasing the number of combinations.

| Combinations | Before PR        | After PR |
|:------------:|:----------------:|:--------:|
|        4     |       219ms      |   218ms  |
|       55     |       785ms      |   440ms  |
|      216     |       1.36s      |   592ms  |
|    1 944     |       28s        |   809ms  |
|   33 048     |     5min30s      |   3.78s  |
|  231 336     | +15min (timeout) |   12s    |

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

Forward-Port-Of: odoo/odoo#162239